2021年8月25日，公司正在积极将该项目推进到临床试验阶段。这已经是英矽智能在6个月内第二次发布全新的临床前候选药物。今年2月，上海，英矽智能刚完成了行业首次用人工智能贯穿药物发现环节（包括机制发现、靶点发现及找到新化合物）的过程，晴天。
惯例，成功发现发现了一种全新机制的用于治疗特发性肺纤维化的临床候选新药，分享一段喜欢的文字，并成功通过多次人类细胞和动物模型实验验证，避免自己成为高知识低文化的汉子：
世界上没有什么东西能拿我们怎么样，是为全球首例，可是我们自己老是想恢复失去的东西，且用时仅18个月、投入仅260万美元。英矽智能首席科学官任峰博士（右）结合本次发布的全新临床前候选化合物，老想着过去，自纤维化药物发现项目启动以来，这样就会毁了我们自己。
在上篇文章介绍了ODX组成分，英矽智能在约24个月内发现了两种临床前候选药物，链接如下：
在UML建模后，分别用于治疗特发性肺纤维化和肾脏纤维化。这侧面印证了候选药物的发现，对诊断的层级结构进行形象描述。当MCD-3D Server对于诊断数据库ODX的调用逻辑取决于ODX数据库架构。
本文基于ISO 22901协议中对ODX架构进行分享。
在ODX层级结构中，并非偶然的运气，内容（值）继承是诊断层之间关系的核心。如下图：
通过上图，清晰说明了继承的层架结构和方向。关于ODX内层级：
PROTOCOL
FUNCTIONAL-GROUP
BASE-VARIANT
ECU-VARIANT
ECU-SHARED-DATA
每一个层级只能继承一组 特定的其他类型诊断层，一个诊断层不能继承同一个类型的诊断层。在图中，层级较高的诊断层属性更“General”，层级较低的诊断层属性更“Special”:
注：只有如下类的对象可以进行值传递（继承）：
⎯DIAG-COMM (its specializations),
⎯DIAG-VARIABLE,
⎯GLOBAL-NEG-RESPONSE,
⎯DOP-BASE (its specializations),
⎯TABLE,
⎯FUNCT-CLASS,
⎯VARIABLE-GROUP,
⎯ADDITIONAL-AUDIENCE,
⎯STATE-CHART,
⎯UNIT-GROUP;
注：
1、只有具有HANDLE属性的类的对象才能进行值传递，具有HANDLE属性对象聚合了其他也具有HANDLE属性的对象，则完整的聚合将被继承，即始终是聚合最外层对象（具有HANDLE属性）是值传递的主题。
2、值继承是为DIAG-LAYER的不同实例之间的对象定义的，因此只有在DIAG-LAYER中定义的类才可以继承。这些类的对象在选定的DIAG-LAYER的D-server API上可查询，查询结果将是该层可见的对象列表。
3、同一类的所有对象在每一个DIAG-LAYER中都应该有一个唯一的SHORT-NAME，即使这些对象不是在这个DIAG-LAYER中定义而是继承的。并且对于SHORT-NAME，当从更“General”层继承的对象可以被更“Special”层所覆盖，从而保证每一个Class的SHORT-NAME的唯一性。对于整个ODX数据库，只有覆盖对象可见（Tester可以通过SHORT-NAME进行诊断内容识别并调用）。
BASE-VARIANT对象通过聚合PROTOCOL-REF对象来创建到PROTOCOL对象的值继承关系。该对象又通过使用《odxlink》引用PROTOCOL对象。
继承层次详情可参考下图：
BASE-VARIANT 对象通过聚合 PROTOCOL-REF 对象来建立到 PROTOCOL 对象的值继承关系，该对象又通过使用 > 引用 PROTOCOL 对象。
一对 DIAG-LAYER 对象之间可能存在本节中描述的值继承关系。禁止同一对对象同时存在两种关系。
如图显示的模型分定义了所有诊断层的共同特征，基类DIAG-LAYER聚合了以下组件：
A：Collection of REQUEST objects
Request是每个诊断服务的组成分，它由诊断仪发送到一个ECU或者一组ECU（以物理寻址 &功能寻址进行区分）以获取所需要的诊断数据或配置ECU的属性。
Request的UML表示描述了这种请求消息的结构，它定义报文内容的一个或多个请求参数（PARAM）组成，ECU解析请求报文，并基于请求给与响应：
B：Collection of response objects (POS-RESPONSE, NEG-RESPONSE, GLOBAL-NEG-RESPONSE)
Response是ECU诊断服务的一分。它由ECU反馈测试人员的请求报文，如下图描述此类响应格式：
ODX中定义了三种类型的响应：肯定响应、否定响应和全否定响应。通常ECU会发送肯定响应报文（POS-RESPONSE）。如果ECU内发生了异常情况，则回复否定响应。
否定响应可能被定义为特定于服务或诊断层实例。
1、在第一种情况下，应通过 NEG-RESPONSE-REF 引用来自服务的 NEG-RESPONSE 来定义否定响应。
2、在第二种情况下，应定义全否定响应（GLOBAL-NEG-RESPONSE）。如果实际服务引用的否定响应不匹配，则该响应应由 D -server自动使用。
C：Document information using the ADMIN-DATA and COMPANY-DATA objects
对于ODX（诊断层或诊断服务），具有很长的声明周期。不可避免受到来自不同公司的不同人员可能进行的许多更改。因此引入该类对象，通过其更改历史记录与ODX对象绑定存储。
与此同时，该内容也包含关负责更改的人员的一些信息。这样问题和反馈就可以发送给正确的接收者。这种数据称为“管理数据”。每个流程合作伙伴还可以将自己公司特定的管理数据添加到 ODX 对象，例如 使用内容管理系统或数据库处理 ODX 对象所需的修订信息。UML模型如下：
D：Collection of FUNCT-CLASS objects:
FUNCT-CLASS 对象在 DIAG-LAYER 中定义，用于对属于 DIAG-LAYER 的 DIAG-COMM 对象进行分类。创建的类别的语义是用户自己定义，在协议中并未专门定义。
E：Collection of DOP-BASE and TABLE objects:
尽管元素 DIAG-DATA-DICTIONARY-SPEC 是可选的，但多数 DIAG-LAYER 实例都会包含它，因为它作为解码诊断消息所需的数据元素的主要容器 .
F：Collection of DIAG-COMM objects and/or DIAG-COMM references:
通过DIAG-COMM对象或其引用的集合——通过模型中的DIAG-COMM-OPROXY捆绑。DIAG-COMM类是DIAG-SERVICE和SINGLE-ECU-JOB的抽象体，该内容会在D-service体现。
G: Collection of ADDITIONAL-AUDIENCEs
ADDITIONAL-AUDIENCE 是一个单独的用户列表，可以启用或禁用这些用户以读取相应的诊断元素。诊断元素可以包含启用或禁用对 ADDITIONAL-AUDIENCE 的引用。如下是UML对additional audience的描述：
H: Collection of STATE-CHARTs
该内容是对车载诊断范畴里两个状态机进行管控：
1) 第一个是描述由执行 DIAG-COMM 导致的可能状态转换。
2) 第二个是描述执行 DIAG-COMM 的先决条件。
如下通过UML描述了Session/Security和STATE-CHART：
I: Collection of LIBRARYs
LIBRARY用于指定不直接执行但由 PROG-CODE 具体定义的可执行代码替代执行。e.g.包含 Java 的 PROG-CODE 元素可能引用描述附加 JAR 文件的 LIBRARY 元素，该文件由Java 代码中的 import 语句包含。LIBRARYs 附加到 DIAG-LAYERs 以允许多个引用而没有冗余。
J: Collection of SUB-COMPONENTs：
如下图表述通过UML形象说明了SUB-COMPONENT的定义。子组件在诊断层定义，被认为是 ECU 内或外的功能单元，涵盖物理上（例如 LIN 从节点）或逻辑上的某些附加诊断相关功能。
以上分享希望有所帮助！
愿你我相信时间的力量，
做一个长期主义者！
-----------------------------------
作者简介 | 穿拖鞋的汉子
汽车电子工程师
公众号：车载诊断技术
来，每天进步一点点！
免责声明：文中图片均来源于网络，如有版权问题请联系我们进行删除！
