《车载SOA软件架构技术规范1.0》解读3：车载SOA软件服务设计规范.docVIP

《车载SOA软件架构技术规范1.0》解读3：车载SOA软件服务设计规范 背景： 本文节选自《车载SOA软件架构技术规范1.0》，该规范是由AUTOSEMO撰写的首个车载SOA软件架构技术规范，也是首个面向汽车行业SOA软件架构的理论体系。近期，AUTOSEMO将组织针对本规范的官方解读，有兴趣的朋友可以关注“AUTOSEMO”，了解更多信息。 本规范分三篇解读： 1、车载SOA架构技术概述及技术规范现状（已发布） 2、车载SOA软件架构设计规范（已发布） 3、车载SOA软件服务设计规范（本篇） 01 车载SOA软件架构：服务设计原则 根据客户功能或系统给出的输入，考虑以下主要服务设计原则定义逻辑功能架构： 1.1 重用 在逻辑功能架构定义期间，定义逻辑工件，以便应在客户功能，系统和域之间按原样重用它们。 如果逻辑元素的功能相同但被实例化了多次，则确保将其创建为重用。这将确保对一个逻辑元素的任何进一步更新将在多个实例之间自动级联。 如果感觉或输入始终需要特定的后处理，则将它们一起封装在BuildingBlock中。这将使整个客户功能／系统中的完整构建块可以重复使用。建议在这种情况下重用完整的构建块，而不是特定的感知元素。 如果执行机构或输出始终需要进行特定的预处理，则将它们一起封装在Building Block中。这将使整个客户功能／系统中的完整构建块可以重复使用。在这种情况下，建议重用完整的构造块，而不是重新使用特定的致动元件。 如果存在一组在功能上相互关联且密切相关的逻辑功能，则将它们一起封装在一个Building Block中。 这将使整个客户功能／系统中的完整构建块可以重复使用。 在这种情况下，建议重用完整的构建块，而不要重用特定的逻辑功能元素。 范例1: 如下图所示，应创建多个重用实例，以实例化车辆中四个车轮中的每个车轮的“ReadWheelSpeed”感应块。 范例2: 要设计车道保持辅助(LKA)客户功能的逻辑体系结构，应该可以重用车道偏离警告(LDW)的逻辑块，并在此基础上构建此新客户功能。 1.2 抽象 应该在正确的抽象级别上仔细考虑逻辑功能体系结构定义中的逻辑元素。 低级别的抽象可能会冒逻辑架构对未来解决方案的适用性丧失（无法重用）的风险。 高级别的抽象可能需要花费更多的时间和精力才能将需求转换为逻辑体系结构。这可能会导致对实际客户功能的错误解释。 例子： 紧急事件触发电子呼叫（紧急呼叫）功能。基于逻辑功能体系结构上下文中抽象的定义，系统工程师只需强调需要感知（检测崩溃事件）和相应的数据流（崩溃事件）的需求。系统工程师不需要回答什么地方，什么地方，这些细节在实施阶段更为合适。 根据基准数据，此客户功能的实际实施在各个汽车制造商之间是不同的： 解决方案1: RCM或安全气囊控制器将碰撞事件数据发布到E-Call主机ECU,以进行后续处理和采取措施 解决方案2: 将E-Call算法包含在被动安全系统中，然后将请求发布到主机ECU以激活E-Call 解决方案3: 将独立的低分辨率G力传感器（加速度信号）直接硬接线到E-Call主机ECU,以进行E-Call激活决策和致动。 1.3 粒度 尽管按照上述标准对逻辑元素进行抽象很重要，但是确保逻辑功能也足够精细同样重要。考虑输入和需要提供哪些输出，逻辑功能应表示紧密相关的功能。具有正确粒度级别的逻辑功能可以灵活地重新部署。 例如，如下图所示：仲裁，启用和处理功能应定义为单独的逻辑块，而不是创建一个称为Process Smart Windows Plus的逻辑块。 1.4 封装 逻辑功能体系结构定义中的逻辑元素应尽可能组合在一起（封装在一起），以便可以在客户功能或系统或域中按原样重用它们。可以使用构件块来实现封装。封装不仅可以确保体系结构的重用，而且其他领域的系统工程师也无需了解构建模块的内部原理，而只需使用公开的巳发布或预订的数据流即可。 例如，定速巡航客户功能的核心逻辑功能应封装在一个构造块中，以便完整的构造块应再次用于（自适应）定速巡航控制客户功能。 1.5 协调 对于逻辑体系结构定义，不同的系统工程师还要处理来自不同域的不同客户功能集。在创建新的逻辑元素之前，系统工程师应始终确保检查其是否巳存在并重复使用。系统负责人和域负责人应确保逻辑体系结构得到协调和重用。以下是典型的工作流程： 处理给定客户功能或系统的系统工程师创建逻辑元素（如果尚不存在）。如果存在，请重用它们。 系统负责人／域负责人需要检查系统工程师的逻辑功能架构，并确定是否存在重复的逻辑元素并进行修复。 系统线索／域线索也应确保将可重用的逻辑元素创建到公共池中。 建议在公共逻辑包中将所有逻辑感测元素与各自的后处理逻辑元素一起构造。 建议??在每个域中使用各自的预处理逻辑元素来构成所有逻辑促动。 应遵循版本管