题目有些太大了，哈哈！不过就是想写这个，大题目小文章吧。也写不长，分几个方面写写个人观察和体会。
一、市场。
小众。几年前听四大四小里面四大之一的一位资深客户讲，全国搞乘用车诊断软件（非数据）开发的也不过120人左右，不大可能超过150人。
主机厂（整车厂）一般会把VCI（俗称诊断仪）的软硬件业务跟其它部件一样：外包。而且也像其它供应商那样：分A、Ｂ两点，互为竞争、备份关系——所谓供应商相争主机厂得利。可以简单地类比：主机厂跟供应商的关系，就像贵得联想都不敢想跟处理器、硬盘、内存厂家之间的关系。
诊断这块分售前和售后，不过业内不这么称呼：售前的叫EOL，End of Line，产线末端，产线指总装线；售后的就叫后市场。诊断上的问题，一般量产前的EOL阶段ECU供应商自己就搞定了，诊断厂家能做的基本是外围整合业务，比如写写配置、配配钥匙之类；售后阶段，整天跟诊断仪打交道的人，就是销售店了。
国内有几家主机厂？一个大的主机厂也不过几百家店，自家店配个一两套诊断仪就可以了，所以你能卖多少诊断仪？
二、行业标准。
起码在诊断上K线通信基本被淘汰；现在绝大部分是CAN，但是CAN也好多年了；其它高级通信协议一般只用在高档车上。这是通信方面。通信嘛，不止用来做诊断的。所以真正算起来，UDS/J2534-PassThru/D-PDU/ODX/OTX这些才算诊断。做ECU的，实现UDS就可以了，其它几个是给诊断仪/诊断软件定的标准。
ISO 14229 UDS是诊断仪和ECU都遵守的标准，规定了诊断指令在各通信协议上的指令格式、诊断服务定义和时序要求。这个做小车诊断是基础必备，都得实现，没得讲。
SAE J2534 PassThru，有2004年的-1和2006年的-2两个版本，之后就没得更新了。这个协议简单，一共就不到二十个函数，许多还是Start/Stop,Read/Write这样成对出现的。去年查过国内一家知名品牌的诊断仪网店，卖得最贵的也不支持这个标准，下面这几个就更不用说了。
ISO 22900，08年出的framework级别的诊断标准。-2部分规定了Ｄ-DPU API，-3规定了D-Server。这个国际知名品牌基本都支持。
ISO 22901，11年出的关于用XML描述诊断数据的标准ODX。以前都是PDF、Excel等格式，混乱不方便机器处理。但是该标准定义的有些宽泛，各厂家或工具在具体表达上有些差异。诊断软件往往要不得不做一些适配工作才可以解析，不过好在数据格式统一了。目前正在实质性的普及阶段。
ISO 13209，12年出的关于用XML描述诊断流程的标准OTX。严格说该标准是11年出的，但是11年的-1没具体内容。一句话：诊断流程图的XML表示，含HMI。国际市场上也有成熟的工具，但是国内刚开始试用。
为何高级标准在国内普及得慢？市场小、细节多实现复杂、投入大应该是主要原因。
三、安全。
这个词是万金油，嘿嘿。绝大多数中低端车的CAN报文都是明文传输。所以新闻上讲黑客黑了人家汽车，又是这又是那的瞎咋呼。要黑什么才有水平？一安全认证算法，二线路加密报文的破解。小诊断仪厂家为什么要辛辛苦苦地做逆向？就是抓人家报文然后根据UDS倒推这报文是干什么的。有些重要操作得一问一答地认证之后才能做，每次问得还不一样，这就叫安全认证。他们为什么拿不到安全认证算法？你想想主机厂能把这东西随便给别人吗？那是他们家的钥匙！
四、开放竞争
与计算机互联网相比，汽车诊断行业，或者就大胆说汽车行业吧，真的是个很保守的行业。主机厂在技术上严重依赖供应商，都形成惰性了——反正有供应商帮我解决，出了问题也是供应商的，我顶多有个失察的罪——都是国企或有那啥背景的——可不能出事——安全第一。所以这就是为什么近几年有那么多新玩家跳进这个圈子，也造造汽车，不怕不指望靠政府关系补贴前进的主机厂能在技术革新上形成实质性的挑战？
五、研发
这个摆脱不了大环境的影响：先把东、西、做、出、来，有问题咱在改。大家都这么玩，你不玩人家也不跟你玩。所以别说有时间做做基础工作，就连软件开发中基本的代码级测试，有几家做的？研发投入跟产品质量有个平衡，当然还有其它平衡关系，但是光抱怨差旅费比例大不行，不能光瞅秤杆不看秤砣秤盘。