离散事件系统导论_实时控制系统的时序模型及其在AUTOSAR系统仿真监控中的应用-3 Related Work...

原文引自：

Frey, Patrick. "A timing model for real-time control-systems and its application on simulation and monitoring of AUTOSAR systems." (2010).

本文仅用于自学和交流使用，未经允许请勿转载~

在本章中，讨论了来自实时计算机系统（电信领域，航空领域，汽车领域）和控制工程领域的不同领域的相关相关工作。图3.1显示了所考虑的相关工作的概述以及它在时间线上产生的项目。这些项目可以是个别研究人员，团体或公司的具体目标研究项目，也可以是工业和学术联盟的公共资助项目和标准化举措。在下文中，还描述了这些项目的范围及其关系。

图3.1：相关相关工作概述

3.1控制工程领域

控制工程领域中涉及控制应用的时序方面的相关研究或多或少独立于其他领域的工作。然而，在控制工程领域中众所周知，由于在潜在分布的实时计算机系统中可能发生的影响，可能对控制性能产生负面影响[85]。这些效果可以阻止和抢占任务和网络消息，具体取决于所选的调度策略及其配置。性能降级效应可以是非零常数或甚至时变延迟，其对反馈路径有效，传感器处的采样抖动或致动器处的致动抖动以及不同步的采样或致动动作如果使用多个传感器或致动器装置。在下文中，讨论了来自控制工程领域的相关相关工作，其考虑了从控制工程角度以及实时计算机系统角度的时序方面。

T'orngren的工作

基于输入采样离散时间控制理论的基本原理，Tüngren[84]首先研究了离散时间控制应用的建模和设计[2]及其作为分布式实时计算机系统的实现，其次是诱导效应由后者控制性能。

Torngren定义了一个最小但足够的概念框架，用于控制应用程序结构的建模和触发行为的规范。建模概念基于可以分层聚合的逻辑功能的概念。除此之外，T-orngren还描述了控制应用程序需要考虑哪些特定于应用程序的时序要求，以及如何将这些要求表示为控制通过框架描述的应用程序模型的注释。Torngren描述的时间要求，即

•可忽略的小或恒定反馈路径延迟

•等距采样和驱动动作

•如果采用多个传感器或执行器，相关采样或驱动动作之间的同步

与我们从4.1节中的离散时间控制理论得出的结果相同。

控制应用程序设计和实时计算机系统实现之间的联系是假设逻辑功能是通过在固定优先级抢占式调度策略下调度的实时任务来实现的。然后，Torngren确定定时属性的方法是一种基于公式的方法，它将实时计算机系统的特定调度引起的影响（阻塞，抢占）考虑在内。然而，为了评估AUTOSAR系统中时序要求的满足程度，该方法不能直接应用，因为Torngren的框架和AUTOSAR的概念不能直接兼容。

作为一项重要的观察，Torngren指出，随着离散时间控制理论和实时计算机科学多年来不断发展，控制工程与实时系统学科之间存在明显的差距。

Torngren对框架的一个很好的概述可以在[85]中找到。通过逻辑功能描述控制应用的结构和触发行为的概念后来在EAST-ADL中进行了调整（参见汽车领域的相关工作）。

Nilsson，Bastian和Wittenmark的工作

在[89]中，Nilsson，Wittenmark和T¨orngren描述了实时控制应用的时序问题。基于此，Nilsson [60]研究了网络控制系统中时间延迟的影响，即实现为分布式嵌入式实时计算机系统的控制系统。

根据Nilsson的工作，Bastian [14]分析了控制回路中的时间延迟。可以通过Bastian方法分析的控制应用程序必须适合特定的分层结构，这意味着不能分析所有可能类型的控制应用程序。

为了确定诸如反馈路径延迟的定时属性，巴斯蒂安引入了基于公式的方法，其中导出了时间延迟的概率分布。直方图用于显示该统计分析的结果。该方法假设控制应用的所有部分（即传感器，控制器和致动器）周期性地执行并且以同步或异步方式通信，这取决于它们的触发速率的关系。

Bastian也可以从隐式假设全局理想时钟的模拟中获得时序属性。结果可视化为面向运行时的图表 - 也称为[88]中的延迟时间历程 - 其中确定的路径延迟的发展随时间显示。后一种图类似于我们的时序示波器图。然而，Bastian和Wittenmark仅显示路径延迟，而我们也使用时序示波器图来显示有效采样和激励速率，以及多个传感器输入数据采集之间的同步或多个执行器的输出数据实现。此外，没有描述如何构造这些图。

其他工作

在控制工程领域，已经在另一个方向上进行了进一步的工作。Cervin [17]提出了反馈调度的方法，其中实时计算机系统的调度程序被视为可以动态控制的过程。该方法要求可以在线调整重要的调度参数，例如任务的周期或其优先级，即在运行期间，以便补偿由实时计算机系统执行的控制应用的过载情况或性能下降。然而，这些参数在实际的工业OSEK或基于AUTOSAR的系统中无法调整，因为这些系统采用静态调度策略（固定优先级抢占），其中参数在运行时之前是固定的。Colom [19]的工作也走向了类似的方向。

3.2电信领域

自20世纪70年代以来，在并行和分布式计算机系统的性能分析领域进行了大量研究。并行计算机系统是在计算节点中具有多于一个处理单元的计算机系统。分布式计算机系统由通过网络互连的多个计算节点组成。已经开发了并行和分布式计算机系统，用于具有单个处理器的计算机系统的计算能力不足的应用，例如，计算密集型问题，例如天气预报，或者应用程序需要空间分布的设备，例如，银行系统的终端站。

在20世纪80年代，电信领域是在大规模生产的商业产品中采用并行和分布式系统的第一个领域（例如，数字电话系统）。在汽车领域，自20世纪90年代初以来，车辆的电气/电子系统已发展成为复杂的分布式计算机系统。最近，并行计算机系统也以双核和后来的多核电子控制单元1的形式进入电气/电子系统。

自20世纪70年代中期到20世纪90年代中期，在埃尔兰根 - 纽伯格的弗里德里希 - 亚历山大大学，对并行和分布式计算机系统的性能分析进行了全面的工作。在下文中，基于他们的研究讨论了并行和分布式计算机系统的性能分析，后来主要涉及电信领域。

基于监测的并行和分布式计算机系统性能分析

评估并行和分布式计算机系统性能的广泛应用方法是在监视或模拟的帮助下分析其动态运行时行为。与基于抽象数据的静态分析方法（例如，在调度分析方法中的最佳情况和最差情况执行时间）相比，基于监视的方法允许观察系统中实际出现的行为及其时序。这不仅对调试目的有用，而且对确定时序属性也很有用。这允许在系统运行期间的每个时间点评估定时要求的满足程度。

并行和分布式计算机系统的性能分析的基础是基于对可在这些系统中监视的事件的因果和时间顺序的仔细考虑。重要的是，即使在分布式系统的不同部分中监视事件，也要正确地排序事件，以便在原因和结果之间得出安全的结论。

为了监视并行和分布式计算机系统的动态行为，需要一个由特定技术设备和用于分析监视事件的软件组成的监视系统。

图3.2显示了并行和分布式计算机系统的监控系统的概念架构。

图3.2：分布式监控系统的概念架构（图[48]改编）

这种系统的主要部分是：

•并行的分布式监控系统，可与要监控的并行和分布式计算机系统无缝集成，即所谓的对象系统。为此，在埃尔兰根 - 恩伯格大学开发了“Zahmonmonitor”（ZM）测量监测系统。ZM4是一系列开发中最新，最通用的2版本。

•灵活的分析软件，通过该软件可以分析来自监控系统的事件跟踪以及结果是否充分可视化。为此，开发了分析软件包SIMPLE [58]。

这种监视系统原则上也可以用于诸如符合AUTOSAR的电气/电子车辆系统之类的目标系统。

在我们自己的工作中，我们专注于

•生成可用于监控和实时模拟AUTOSAR系统的性能分析的软件工具。仪器构成监控系统的一部分，但与对象系统集成。

•通过监控或模拟获得的事件跟踪文件的分析以及针对控制应用程序时序的分析结果的特定于应用程序的解释。

图3.2中以灰色突出显示的部分是我们的工作提供概念贡献的领域。

Contributions by Mohr莫尔的贡献

基于分布式监控系统ZM4，Mohr [57]开发了一种灵活的软件，用于分析名为SIMPLE的事件跟踪文件[58]。Mohr描述了基于分层软件体系结构的这种分析软件的主要体系结构（见图3.3）。最低层是监视器层，其中事件从对象系统获得并存储在事件跟踪文件中。Mohr描述了如何构造事件记录和事件跟踪文件，以便在特定事件发生时（时间）和位置（位置）时可以明确地识别它们。为了从监视分布式计算机系统的事件跟踪文件中获取单个一致的事件跟踪文件，Mohr描述了如何合并从多个计算节点获取的事件跟踪文件。这是数据访问层的任务。选择层提供在事件跟踪文件中导航的功能。工具支持层提供通用实用功能，例如统计功能。工具层实现了分析事件跟踪的不同方式。这包括事件跟踪验证，统计分析以及系统运行时行为的可视化。SIMPLE提供不同类型的统计图（例如，直方图）和面向运行时的图（例如，状态图，甘特图）以可视化分析结果。

图3.3：基于事件的分析系统的分层软件架构（图[57]改编）

我们工作的重点主要放在工具层，我们提供新算法来分析因果链和新形式的运行时导向图（定时示波器图），以充分可视化结果。后者与SIMPLE提供的面向运行时的图表相当，但是，它们已经过定制，以显示控制应用程序的时序属性，而不是像SIMPLE那样的反应式实时应用程序。

莱曼的贡献

Lemmen [50]开发了概念，以扩展基于监测的性能分析，如Klar等人所述。[48]通过规范驱动的概念，允许基于形式规范获得对象系统的相关事件和动作的工具。

在电信领域，规范和描述语言（SDL）[15]用于指定正在开发的系统的结构和执行行为。SDL使用通过消息进行通信的进程。消息序列图（MSC）[16]与SDL结合使用，以描述系统组件之间交换的消息序列以及基于逻辑时间轴的相关过程的内部状态。MSC指定消息和进程之间的因果关系。

Lemmen的概念补充了SDL / MSC提供的功能规范手段，因此可以自动获得需要监控的相关事件和动作，以便对对象系统进行适当的行为抽象。

由于通过SDL / MSC建模的电信系统是固有的反应性实时计算机系统（并行和分布式），因此只对这类实时应用进行时序要求的正式描述。尚未考虑控制应用的时序要求。

Munzenberger的贡献

基于基于事件的并行和分布式计算机系统监测的基础，即事件以及这些事件的因果和时间排序原则，Munzenberger等。[56]引入了一种正式的时钟模型，可以精确表征不同类型的时钟（理想时钟，实时时钟，离散和衍生计数器）。正式时钟模型是模拟并行和分布式计算机系统的定时行为的基础，因此可以在规划阶段快速有效地进行性能评估，并与这些系统的开发阶段并行。正式时钟模型在4.2.3节中有更详细的介绍，并用作我们AUTOSAR时序模型的基础。

Munzenberger[69]此外使用正式时钟模型作为基于事件指定实时要求的基础。事件被绑定到正式表征的时钟，使得时钟的读数（即事件的时间戳）变得可比较，使得能够确定定时属性。此外，可以分析诸如时钟漂移的效果。

Munzenberger为时序要求的规范引入的概念假设释放事件类的事件通过逻辑条件与所需事件类的事件相关并且与时间限制相关联。该概念适用于反应性实时应用，例如电信领域中的应用。Müunzenberger根据与SDL绑定的时钟事件，整合了他的正式指定时钟概念和时序要求规范。虽然该概念允许规定反应式实时应用的时序要求。它不直接适用于控制应用，就像在定时要求规范（释放事件，要求事件）中使用的两个事件类一样，信号路径不能充分指定。为此，需要考虑不支持的事件之间的传递因果关系。

3.3航空航天领域

在航空航天领域，分布式嵌入式实时计算机系统领域有一个值得注意的研究和标准化流程，它们在某种程度上也涉及时序方面：这些是MetaH和AADL。

霍尼韦尔的MetaH

MetaH是一种语言和工具集，用于对嵌入式实时应用程序的软件和硬件相关工件进行建模，并将两者集成到一个完整的系统中。这些概念最初是由Hon​​eywell Technology在20世纪80年代后期开发的。该语言和工具集是在DARPA于1991年至1996年间资助的DomainSpecific Software Architecture计划中开发的。在1997年至1999年复杂系统进化设计项目的后续项目中，MetaH工具集得到了扩展。

在MetaH开发时，可用的商业工具主要是为电信领域量身定制的[76]。MetaH的开发目标是航空航天领域，它也有最广泛的应用，主要是在示范项目中，但不是在商业产品中。自2000年初以来，MetaH首先被重命名为航空电子架构和设计语言（AADL），后来又更名为架构分析与设计语言（AADL）。后者由汽车工程师协会（SAE）标准化并进一步开发。关于MetaH的技术和历史概述以及向AADL的过渡可以在[76]中找到。

汽车工程师学会的建筑分析与设计语言

架构分析和设计语言（AADL，[74]，[29]）是一种特定于域的语言，用于描述基于软件的嵌入式实时应用程序，最初是为航空领域开发的，但原则上也适用于汽车领域 。它是MetaH的继承者，并在汽车工程师协会（SAE）标准AS5506 [75]中标准化。

AADL提供了对嵌入式实时应用程序的软件和硬件相关工件进行建模的概念，以及将两者集成到一个完整系统中的概念。通过AADL描述的系统可以针对不同的非功能特性（例如性能和定时）进行分析，还可以分析安全性，安全性和能量消耗。然而，AADL没有解决基于模拟和/或监测的性能评估。

AADL模型通过组件进行描述，其中组件属于三个类别之一：应用程序软件，执行平台或组合。

AADL的一个特定概念是对所谓的流建模的概念。流是系统中的外部可观察信息路径。在应用软件组件中，通过流源，流路和流槽来描述流。流路径可以使用定时属性进行注释，以表示数据沿路径传播所花费的时间。

在[30]中，Feiler和Hansson为AADL提供了一个流延迟分析框架，可以确定“信号流数据的端到端延迟和时间以及它们的抖动。”流延迟分析框架针对控制应用因为它们首先具有关于传感器和致动器之间的相关采样和致动动作之间的等待时间的定时要求，其次具有恒定采样和致动速率的维持。

虽然流程分析框架针对离散时间控制应用程序的特定应用程序特定时序要求，但它无法提供合适的方法来准确确定相应的时序属性：首先，只有最佳情况和最坏情况分析才能通过这种方式，控制应用的特定应用时序要求得不到充分解决，其次只能分析一组有限的AADL系统，因为基于公式的方法不考虑AADL提供的所有建模选项。此外，由OSATE的流延迟分析插件执行的计算，SEI开源AADL工具环境，提供流分析框架的实现，几乎不可追溯。

与AUTOSAR和EAST-ADL类似，AADL采用基于组件的方法，允许将应用程序结构化为可以分层聚合的组件。包含在AADL中的流路径的概念也是分层的，因为通过组件的流路径可以由包含组件的其他流路径组成。我们为AUTOSAR提供了类似的概念，用于信号路径的正式描述。这允许充分描述特定于应用的时序要求，尤其是控制应用的时序要求。

3.4汽车领域

在汽车领域，由于降低成本的高压，汽车制造商（OEM）和他们的一级供应商紧密合作。在诸如公共资助的应用研究项目或标准化举措等共同倡议中开展了大量工作，以商定共同概念。联合举措由工业合作伙伴（OEM，一级供应商，工具供应商），研究机构和大学的联合体进行。在下文中，描述了与我们的工作相关的几个这些举措的范围和关系。

EAST-EEA（EAST-ADL）

在2000年代早期，汽车行业面临着汽车电气/电子系统开发日益复杂的问题。软件通常是专门为单用途专用电子控制单元（ECU）开发的。实现主要独立于特定车辆的车辆功能（例如，控制应用）的应用软件既不能在其他项目中重复使用，也不能轻易地迁移到另一个ECU。其原因是微控制器特定的实现以及实现车辆功能的应用软件与执行应用软件的ECU的平台软件的紧密耦合。为了管理不断增长的开发复杂性，需要为汽车领域量身定制的新概念。建立了由几家工业公司（OEM，一级，工具供应商）以及研究机构和大学组成的联盟，并在2001年至2004年期间开展了一项名为EAST-EEA [45]的联合公共资助研究项目。

在其中心，EAST-EEA项目定义了系统模型的本体，即 一组相互建立的系统模型，每个系统模型代表了在不同抽象层次上完整车辆的电子车辆特征和功能开发的相关方面。在某个抽象级别上的系统模型被解释为在开发的特定阶段表示的系统。系统模型的本体包括五个抽象级别：车辆特征级别，分析级别，设计级别，实现级别和操作级别。分析和设计级别的体系结构通过逻辑功能表示不同粒度的车辆的功能。实现级别的体系结构代表软件和硬件实体的功能。操作级别包含表示电气/电子车辆系统的实际工件，即硬件平台和在其上运行的代码。

用于描述不同体系结构的建模概念在EAST-ADL [46]中描述，这是由EASTEEA项目定义的体系结构描述语言。Torngren工作的影响可以在函数体系结构的建模概念中找到[46]。逻辑功能用于指定要在电气/电子（E（/ E）系统（例如，控制应用）中实现的车辆功能的结构和触发行为。但是，作为指定应用特定时序要求的手段在Torngren的工作中非正式的，这些都没有被引入EAST-ADL。

除了作为EAST-ADL一部分的建模概念外，EASTEEA项目还为汽车电子控制单元（ECU）定义了以中间件为中心的ECU软件架构[80]。其想法是通过对应用软件透明的中间件来分离并因此将实现车辆功能的应用软件与底层平台软件（操作系统，通信堆栈，I / O驱动器）分离。这使得能够在不同的开发平台和不同的项目中重用应用软件，并且简化了电子控制单元之间的应用软件的迁移。以中间件为中心的ECU软件架构是AUTOSAR计划标准化的主要目标

EAST-ADL的一个限制是它不包含任何关于特定应用时序要求描述的概念，或者如何处理任何与时序相关的工程信息。

ATESST（EAST-ADL2）

ATESST项目[77]是EAST-EEA项目的继承者，于2006年至2008年进行。当时，AUTOSAR联盟已经发布了以前形成EAST-EEA系统模型重要方面的概念。这些首先是在实现级别和操作级别上使用的概念，其次是分层ECU软件架构的概念。此外，其他标准化机构（如对象管理组（OMG））已经发布了统一建模语言（UML2.0）[61]的更新以及系统工程中称为SysML（系统建模语言）[63]的特定配置文件。

因此，ATESST项目的目标是：

•将EAST-EEA项目的EAST-ADL概念与当时AUTOSAR标准的最新概念保持一致。为此，AUTOSAR为其概念形式化选择的元建模方法适用于EAST-ADL，EAST-EEA系统模型的操作级别和实现级别的专有概念被相应的AUTOSAR概念所取代。

•使EAST-ADL的概念与SysML的概念保持一致。这是通过将EAST-ADL的功能建模概念基于SysML的概念借助两个元模型的集成来实现的。

•将EAST-ADL与UML2.0对齐。定义了UML2.0配置文件，以便EAST-ADL2可用于支持UML2.0配置文件的现成UML2.0建模工具。

ATESST项目的努力产生了EASTADL的更新版本，即EAST-ADL2 [47]。

EAST-ADL2还包含超出EAST-ADL和AUTOSAR [35]原始概念的其他概念。这包括用于描述与功能模型（分析和设计级别）或软件架构模型（实现级别，即AUTOSAR）正交的时序要求的概念。通过级联事件链将时序要求注释到系统模型工件，其中事件指向功能或软件实体的端口。虽然总体思路朝着正确的方向发展，但是EAST-ADL2中提供的解决方案在技术上并不合理，因为表达因果链的概念并不精确。例如，不可能生成用于模拟或监视的仪器，使得可以评估定时要求的满足程度。

系统模型的细化概念（即，从设计级模型的分析级模型到实现级模型）也反映在如何处理时序要求：来自更高架构抽象级别的系统模型的时序要求是在较低的体系结构抽象级别上对系统模型的时序要求进行细化。

然而，在EASTADL2中缺少用于确定定时属性的具体概念 - 基于分析，模拟或监控的概念。因此，EAST-ADL2仅仅不足以支持评估特定应用时序要求的满足程度的用例。

AUTOSAR

2003年，汽车开放系统架构（AUTOSAR）倡议[5]成立，作为工业标准化组织。目标是标准化汽车嵌入式系统开发的大量非竞争性方面，以降低开发复杂性，从而降低开发时间和成本。AUTOSAR是几个以前存在的汽车标准的继承者，如OSEK / VDX [65]，CAN [33] [64]，Flexray [32]和LIN [51]，并将它们集成到严格的行业标准中。虽然这些标准的概念已集成到AUTOSAR中，但之前的标准化机构已停止进一步开发其概念（例如，OSEK / VDX）。

AUTOSAR的主要成就是

•标准化，分层的ECU软件架构及其中间件层，即所谓的运行时环境（RTE），

•用于描述应用软件的软件组件技术，支持分层软件架构和不同的通信模式，

•以及描述的方法如何构建符合AUTOSAR标准的系统。

对于基于中间件的分层ECU软件架构，AUTOSAR的灵感来自EAST-EEA项目的创意。然而，并非所有在EAST-EEA项目中开发的概念都经过调整。例如，没有考虑作为EAST-ADL一部分的功能建模的概念。AUTOSAR的重点是EAST-EEA系统模型的较低抽象级别，即实现级别和操作级别。

对于其软件组件技术，AUTOSAR的灵感来自MSR-SW标准的概念[53]。MSR-SW包含用于分层应用软件体系结构建模的概念和基于XML的数据交换格式，以便于车辆制造商和供应商之间的工程信息交换。但是，MSR-SW仅限于单ECU系统，而AUTOSAR则适用于单ECU系统和分布式系统。

AUTOSAR倡议采用了几种方法来定义构成时间模型的概念。但是，这些方法都没有产生合理的概念，使AUTOSAR系统的开发人员能够评估特定应用时序要求的满足程度。在下文中，简要讨论了这些方法。

2004/2005年，成立了第一个内部工作组，讨论了时序要求描述和时序特性确定方面的问题和潜在解决方案。然而，该小组未能提供正式成为该标准的解决方案。有人认为，这些问题需要研究，标准化机构无法直接解决。但是，由于AUTOSAR没有发布中间结果（例如，问题规范报告），研究团体无法直接解决这个问题并提出解决方案。时机仍然是一个悬而未决的问题。

在AUTOSAR（2006）的3.0 / 3.1版本中，已经提出了AUTOSAR的时序模型作为虚拟功能总线（VFB）规范的一部分[12]。但是，此时间模型已明确标记为非正式，仅供参考。我们已经确定了关于时序模型的拟议概念的若干问题。首先，时序模型中描述的具体事件并不精确。目前还不清楚AUTOSAR系统中何时（时间）和这些事件发生的位置（位置）。这可能导致模糊的信号路径描述。关于AUTOSAR通信模式的另一个问题是仅考虑三种通信模式中的两种（不处理可互通通信）。另一个问题是隐含和显式发送器/接收器通信模式对定时行为的可能影响未被涵盖。然而，后者对于充分处理由于发送器/接收器通信模式的具体选择而导致的定时行为的差异很重要。时序模型还缺乏表达特定于应用的时序要求的概念，例如我们为控制应用得出的时序要求。因此，不可能为这一类重要的实时应用指定特定于应用的时序要求。而且，不清楚如何确定相应的定时特性，以便可以评估定时要求的满足程度。

从2007年到2009年，一个名为TIMMO（TIming MODel）的联合公共资助项目[81]由汽车领域的工业合作伙伴（OEM，第1层，工具供应商）和大学组成的联盟进行。目标是为汽车嵌入式系统开发定义时序模型，并描述如何在开发阶段处理与时序相关的工程信息的方法。不是发明新的架构描述语言，而是决定将EAST-ADL2和AUTOSAR作为参考架构并基于这些来定义新概念。

TIMMO项目的结果首先是基于EAST-ADL2和AUTOSAR的定时增强描述语言（TADL），其次是描述如何应用TADL的方法。

TADL包含基于事件链描述时序要求的概念，也称为时序链。时序链使用的TADL特定事件是指AUTOSAR软件架构中EAST-ADL2功能架构中的结构元素。这样做的问题在于，这些事件发生的时间和地点，以及如何监控此类事件没有明确的基础。实际上，当涉及在实时系统中监视此类事件时，存在许多开放性问题，例如将仪表指令放在AUTOSAR系统的源代码中的何处。

TADL时序链的概念是将时序链段连接到从传感器到执行器的时序链。遗憾的是，开发的概念与允许在EAST-ADL2中建立功能层次结构或在AUTOSAR中的软件组件层次结构中的概念不能很好地集成。这是有问题的，因为不可能进一步使用这些信息，例如，以获得用于监测或模拟的仪器。

TIMMO方法描述了如何在开发的不同阶段之间导出和传递工程信息。对于后者，EAST-ADL2的抽象级别被解释为开发的不同阶段。

2008/2009年，在AUTOSAR联盟内设立了第二个内部工作组。由于第二个内部工作组与TIMMO项目之间的生动交流，AUTOSAR概念非常类似于TADL概念。该工作组的结果现已成为AUTOSAR标准最新版本4.0（2010年初）的一部分。然而，这些概念与TADL具有相同的缺陷。

总之，我们可以说已经有几种方法可以用于AUTOSAR的时序模型，但是，它们都没有提供完善的解决方案。

基于表示信号路径的事件链描述时序要求的想法原则上与我们在工作中遵循的相同。

然而，虽然我们的工作目标是在正式规范生成的仪器的帮助下进行仿真和监控，然后分析事件跟踪文件并确定适当的时序属性，但现有的想法尝试整合来自正式时序分析方法的概念（ 例如，调度分析）。然而，后者不能正常工作，因为该方法到目前为止仅在概念上被描述，但在技术上没有被评估或证明。这些想法的技术实现也不令人满意，因为不清楚如何使用官方AUTOSAR或TIMMO概念可以指定的信息。新的时序模型概念与AUTOSAR的现有概念的集成也没有很好地实现，因为它带来了歧义。此外，所考虑的时序要求仅关注于无功实时应用，并未充分考虑在汽车领域中重要的控制应用的特定应用时序要求。

其他相关工作和工具

除了迄今为止讨论的相关工作外，还有进一步的相关工作已经进行并应该提及。此外，与AUTOSAR相比，基于类似概念的工具以及与电信领域中基于监控的性能分析工具相当的工具。这些也在下面描述。

ASCET

ASCET [28]是ETAS GmbH的工具套件，用于汽车ECU软件的规范，设计和实施（通过自动代码生成）。ASCET基于Eppinger [20]和博世企业研究（Bosch CR）在20世纪80年代末和90年代初期开发的概念。

对于行为规范，ASCET提供了关于框图和状态机规范的图形方法（类似于MathWorks的Matlab / Simulink [78]和Stateflow [79]），或者作为文本符号的专有嵌入式软件描述语言（ESDL）。对于软件体系结构的规范，ASCET提供了自己的建模概念，以从C代码实现中抽象出来。这些概念以特定方式相互结合使用：ASCET项目代表一个ECU软件开发项目，由称为ASCET模块的单可实例化组件组成。ASCET类是可以在这些模块中一次或多次实例化的组件。ASCET模块包含所谓的进程，这些进程对驻留在全局名称空间中的消息进行操作，并且可以由其他模块中的进程发送或接收。

ASCET在多种意义上类似于AUTOSAR：

•首先，ASCET提供了通过组件指定分层软件体系结构的方法。模块和类与AUTOSAR中的原子和复合软件组件相当。

•其次，ASCET包含一个概念，用于防止由于打算并行访问同一消息的进程的读/写冲突而导致的数据不一致。该概念是自动为可能发生潜在读/写冲突的进程提供消息副本。消息复制通过代码生成自动提供。当Runnable实体通过隐式发送器/接收器通信进行通信时，AUTOSAR ECU系统中的运行时环境实现了类似的概念。

虽然ASCET类似于AUTOSAR，但它并未提供指定特定于应用程序的时序要求的概念。因此，不可能将现有的解决方案从ASCET调整为AUTOSAR。

Spider/ TITUS

Spider / TITUS工具套件[21]是在ETAS GmbH，Vector Informatik GmbH和Daimler AG之间的联合项目中开发的，解决了分布式汽车ECU软件应用软件的分而治之的需求。虽然Spider / TITUS工具套件有几个概念上类似于AUTOSAR的概念，例如 可以分层聚合到软件架构中的组件，它从未作为商业产品开发，仍然是研究原型工具。Spider / TITUS工具套件也没有提供描述特定于应用程序的时序要求的概念。因此，也不可能使现有解决方案适应AUTOSAR。

Performance Analysis Tools in the Automotive Industry

虽然基于监测的性能分析并未广泛应用于汽车行业，但仍存在允许监控和调试汽车ECU系统的工具。例如，ETAS GmbH的RTA-TRACE [26]是基于OSEK的汽车电子控制单元的监控解决方案。监控仪器直接与实时操作系统集成，以便可以监视诸如任务的启动或终止之类的有趣事件。

原则上，RTA-TRACE与ZM4 / SIMPLE相比具有类似的架构，除了它针对单个ECU系统而不是分布式和并行计算机系统。虽然可以将RTA-TRACE扩展到并行和分布式实时系统，但这不是我们工作的目标。

由于开发基于RTA-TRACE的分布式监控系统（如ZM4）的努力非常高（例如，在开发合适的硬件接口方面付出了巨大努力），我们专注于单ECU AUTOSAR系统并使用RTA-TRACE进行实验和案例研究。对于分布式AUTOSAR系统，我们的概念需要分布式监控系统，例如ZM4。我们开发的分析算法可以集成到SIMPLE中。作为替代方案，RTA-TRACE可以通过概念扩展，以建立基于同步测量时钟的全球时基。作为ECU的接口，可以使用ETK-device3。ETK设备广泛用作高性能ECU访问设备以及测量和校准软件，以便调整汽车功能的参数。