对于基于模块化软件部件和其他储存软件的产品发展，使用了汽车标准软件核心（SSC）。标准软件包含了所有可以标准化的任务，也就是说，这些任务在某种程度上与指定范围无关。比如，这些任务就像控制硬件驱动器、识别并储存出现的错误，以及控制网络的链接。这些功能可当做分开的、可重复使用的模块来实施。所有这些标准化的软件组件就是SSC。
SSC是ECU软件的一部分，其中的软件复用早已实施——即使ECU的供应商变换了。一个软件组分的可重复使用的程度取决于软件的分类，正如8.3.2节所提到的。
图8.6展示了大众集团里的SSC结构。首先，它包括了一个符合OSEK标准的操作系统[18]。通信驱动程序（CAN和LIN）是高层协议组件的基础，它们包括：网络管理（NM）、控制和显示协议（BAP，德国用于操作和显示协议）、传送协议（TP）或信号滤波层OSEK COM[19]。诊断功能由模块“诊断处理者”和“标准诊断服务”所支持。基本硬件提取由输入/输出（I/O）驱动程序和库模块来施行，它们负责处理与EEPROM、模拟-数字转换器、脉宽调制器、外部接口等的接驳。最终，一个单独的、引导加载程序软件通过汽车的诊断界面，允许对每一个带刷新内存的ECU编程。更详细的解释可以在文献[20]中找到。
图8.6 SSC的案例：大众团队的SSC
SSC不仅支持与硬件无关的界面，而且也支持被实际应用软件使用的、在微控制器上的完整基础架构服务。这种服务也促使了不再依赖使用的微控制器平台的应用程序的研发。
SSC和功能软件之间的界面一般通过应用程序界面（API）来实现。API的一个典型例子就是OSEK COM规范。所描述的这个功能库包含了所有构建标准化软件模块API的必要信息。因此，正如8.3.2节所提到的，标准化软件模块的组合体现了软件有效重复使用的基础。
因为SSC的架构不但要为重复利用来设计，而且重复利用效果还可以进一步提高。尽管如此，标准化软件依然在功能软件的重复利用上面起着重要作用。考虑到这个方面，一个叫做AUTOSAR的工业公司，在2002年开始了旨在进一步发展和标准化已经存在的标准软件架构的工作[21]。AUTOSAR的规范主要集中在软件组件之间界面和这些组件完成的功能的描述上面。AUTOSAR的规范并不指定特定的实施，因为这些要留给提供AUTOSAR兼容标准软件的供应商来做。
图8.7给出了关于AUTOSAR软件组件和界面的概述。核心元素是AUTO-SAR的运行环境（RTE），它提供了一种通信抽象的应用软件。在我们的术语中，RTE是一款典型的适应性软件。在RTE的正下方，此图表明了系统服务（比如，定时器和计数器）、存储服务（比如，访问EEPROM）、通信服务（比如，把应用程序的信号打包成CAN信息，并以定时的方式管理发送）、I/O访问（比如，模拟-数字信号转换）和称作复杂设备驱动程序（比如，处理需要ECU硬件提供直接支撑且不能标准化的指定应用软件外设）之间的纵向差别。此外，此图也表明了各种服务、抽象层和驱动程序之间的水平差别。
图8.7 AUTOSAR软件架构
更多的有关AUTOSAR（第2章）的信息可以在参考文献[2]中以及AU-TOSAR的网站上查到。
8.3.4.2 研发流程中所需的工具(www.daowen.com)
很显然，到目前为止描述的任何流程都需要工具的支持。在一个典型的研发环境中，工具使用者的目标是通过研发工具间的转换过滤器，获得一个无缝的工具链。当引入功能库的时候，这个做法并不适用。对于一个企业和部门所使用的每一套工具，比如不得不开发的过滤器，它们把数据库中的数据转换到工具中，反之亦然。同时，因为每套工具的语言覆盖范围都不同，所以难免在每次转换都会有一些小的信息遗失。只要沿着V模型的一个方向进行研发，那么是不存在问题的。一旦研发在V模型的不同位置上同时进行（同步工程），那么数据就再也不能自动保持一致性了。
应对这个问题的方法就是像8.3.3节中提到的标准化数据模型。这些工具就是功能库中的数据编辑器。在这种想法下，一个工具链就是一套工作于公共数据库、不需要人工用户交互的工具。
8.3.4.2.1 核心软件研发
核心软件研发所需的工具必须支持不同等级的系统说明：
•需求是使用者对于车辆期待的文本叙述。为了应付这种需求，适用如DOORS那样的工具是有道理的，DOORS具有像自动需求密钥生成、扩展搜索引擎和文本生成可能性的特点。
•接口是一个应用程序或模块的所有连接点，通过这些连接点，信息从各个模块输入或输出。因此需要一个工具来管理这些外部界面。同时内部数据对于调试目的来说，也是有意思的。通过数据字典，可以在一个工具上管理外部界面和内部数据。
•系统架构就是功能网络、硬件架构、硬件与功能网络之间的映射。系统架构可以由统一的模型语言（比如UML）工具或者像DaVinci[6]这样的汽车指定工具来表达。
•特性描述既可以是C语言，也可以是像UML这样不同建模语言建立的模型。汽车工业中，另外一个常见的选择是Matlab/Simulink/Stateflow[25]。像Tar-getlink[26]这样的工具可从模型中生成C代码，即使目标平台并不支持浮点运算代码。
8.3.4.2.2 产品研发所需的工具
大多数标准化的软件组件，如CAN总线的网络驱动程序[27]、OSEK操作系统[18]，都必须适用于指定的网络节点和硬件平台。如果没有充足的工具支持，它们将无法运行。
一个支持这种组件设置的工具需要关于几个控制单元之间联系的信息。每个组件都需要对于组件功能非常重要的特殊的数据。现今设置工具的多样性是因为工具所基于的不同的数据格式。对于系统集成者来说，他是唯一一个知道控制单元间全部联系的人，这意味着需要很大的努力才能处理好几种数据格式和潜在导入错误的风险。因此，必须创建一个应用于通信信息的单一数据库，就像8.3.3节中所提到的。
创建工具通过集成代码生成器实现了软件组件改编。但也可以发现今天的SSC的一个不足。对于整个SSC，没有一个唯一的设置界面，但是许多部件都存在特殊的构建工具。最终，只能优化软件的部件，而缺少一个工具来支撑优化整个系统。这种优化取决于系统研发人员的经验和知识。尽管如此，已经开始努力在一个开放框架中使用统一的用户界面来集成不同的工具。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
