车载SOA软件架构：服务设计原则

根据客户功能或系统给出的输入，考虑以下主要服务设计原则定义逻辑功能架构：

1.1 重用

• 在逻辑功能架构定义期间，定义逻辑工件，以便应在客户功能，系统和域之间按原样重用它们。

• 如果逻辑元素的功能相同但被实例化了多次，则确保将其创建为重用。这将确保对一个逻辑元素的任何进一步更新将在多个实例之间自动级联。

• 如果感觉或输入始终需要特定的后处理，则将它们一起封装在BuildingBlock中。这将使整个客户功能／系统中的完整构建块可以重复使用。建议在这种情况下重用完整的构建块，而不是特定的感知元素。

• 如果执行机构或输出始终需要进行特定的预处理，则将它们一起封装在Building Block中。这将使整个客户功能／系统中的完整构建块可以重复使用。在这种情况下，建议重用完整的构造块，而不是重新使用特定的致动元件。

• 如果存在一组在功能上相互关联且密切相关的逻辑功能，则将它们一起封装在一个Building Block中。

  这将使整个客户功能／系统中的完整构建块可以重复使用。

  在这种情况下，建议重用完整的构建块，而不要重用特定的逻辑功能元素。

1.2 抽象

• 应该在正确的抽象级别上仔细考虑逻辑功能体系结构定义中的逻辑元素。

• 低级别的抽象可能会冒逻辑架构对未来解决方案的适用性丧失（无法重用）的风险。

• 高级别的抽象可能需要花费更多的时间和精力才能将需求转换为逻辑体系结构。这可能会导致对实际客户功能的错误解释。

根据基准数据，此客户功能的实际实施在各个汽车制造商之间是不同的：

• 解决方案1: RCM或安全气囊控制器将碰撞事件数据发布到E-Call主机ECU,以进行后续处理和采取措施

• 解决方案2: 将E-Call算法包含在被动安全系统中，然后将请求发布到主机ECU以激活E-Call

• 解决方案3: 将独立的低分辨率G力传感器（加速度信号）直接硬接线到E-Call主机ECU,以进行E-Call激活决策和致动。

1.3 粒度

逻辑功能体系结构定义中的逻辑元素应尽可能组合在一起（封装在一起），以便可以在客户功能或系统或域中按原样重用它们。可以使用构件块来实现封装。封装不仅可以确保体系结构的重用，而且其他领域的系统工程师也无需了解构建模块的内部原理，而只需使用公开的巳发布或预订的数据流即可。

例如，定速巡航客户功能的核心逻辑功能应封装在一个构造块中，以便完整的构造块应再次用于（自适应）定速巡航控制客户功能。