CN114761915A - 用于在复杂功能系统的系统开发或验证方面制定可执行规范的方法和软件工具 - Google Patents

Abstract

本发明涉及一种用于在针对目标设备、尤其是针对机动车的功能系统的系统开发和/或系统验证方面制定可执行规范的计算机实现的方法，该方法包括如下步骤：提供包括用于目标设备控制或调节的一个或多个功能（F、F1、F2、F3、F4）的功能系统的至少一个模型视图；提供选择界面，该选择界面被设计用于由用户在所提供的第一模型视图中选择和更改系统部分；将在该第一模型视图中所选择和/或所更改的系统部分转变并且显示在针对该用户的至少一个相应另外的模型视图中；提供规范和发布界面，该规范和发布界面被设计用于选择和/或检查和/或进一步适配在至少一个相应另外的模型视图中所显示的系统部分或更改并且被设计用于由用户来发布在第一模型视图和/或至少一个相应另外的模型视图中进行的对系统的更改；将所发布的对系统的更改自动化地采用到至少一个相应另外的模型视图中。

Description

用于在复杂功能系统的系统开发或验证方面制定可执行规范 的方法和软件工具

技术领域

本发明涉及一种用于在针对目标设备、尤其是针对机动车的功能系统的系统开发和/或系统验证方面制定可执行规范的计算机实现的方法。本发明还涉及一种相对应的软件工具以及一种控制单元，该控制单元被设立为实施所提到的方法。

背景技术

基于模型的系统开发方法（Model-Based Systems Engineering，MBSE），诸如从Pohl, Klaus, Manfred Broy, Heinrich Daembkes和Harald Hönninger的“Advanced Model-Based Engineering of Embedded Systems – Extensions of the SPES 2020 Methodology”，Springer，2016年中公知的建模平台，在复杂功能系统的开发方面越来越普遍，这些复杂功能系统尤其是实现在汽车应用中的用于自动化驾驶或用于改善车辆的能效的创新功能。在此，例如用于称为SysML或OMG SysML（OMG系统建模语言，注册商标，ObjectManagement Group, Inc.）的图形建模语言的软件工具，或者E/E架构开发工具（E/E架构在此代表“电气-电子架构”，该架构尤其描述了在车辆中存在哪些电气和电子组件以及使这些电气和电子组件彼此交互）、诸如PREEvision（注册商标），适合于在系统开发的早期阶段以功能或逻辑模型视图的形式来描述即使复杂系统的逻辑-功能关系或因果关系。

这种类型的现有的已知方法允许以功能性及其依赖性的形式来对系统进行结构化描述。后者通常以接口描述的形式来被指定。对功能系统的这种结构化描述在本文中也称为静态系统描述。在此，向用户或系统开发者提供静态模型视图，诸如静态功能系统描述，其包括：一个或多个功能因果链（英文：Cause-effect-chain），所述功能因果链描述了涉及目标设备中的物理功能性的影响和目标参数之间的因果关系；或者功能架构，在该功能架构中，不同因果链的功能相同部分被聚合并且按照功能从属关系以层次分解来被排列。

除了结构化描述之外，使用复杂功能系统的行为描述，该行为描述通常限于因果关系、具有时间要求的序列或者借助于状态机对面向状态的系统的描述。在已知的方法中，对时间连续调节或控制系统的动态系统行为的描述与借助于专用软件仿真工具、诸如MATLAB/Simulink（注册商标）进行的结构化描述解耦。

在此，结构化的静态模型视图与动态行为描述的耦合被委托给使用者。现有的各个解决方案是单向的，并且如果有的话只具有不同模型视图的各个建模元素之间的有限语义耦合。原因在于本领域技术人员公知的以下事实：正如用于动态行为描述的SysML工具不那么适合一样，用于动态行为描述的软件工具也不支持所有必要的静态模型视图。例如，常见的待建模制品、诸如整个用例（use cases）、各个特征（features）和功能及其接口和变体、在静态或动态描述中的因果链或者E/E结构在系统开发的早期阶段并不能分别通过全部三个不同的软件工具——首先是适合的需求工具（requirements tooling），其次是SysML并且第三是MATLAB/Simulink——来被完全支持。因此，也无法在此使用单个工具来描述所有需要的模型和视图以便比如确保不同模型视图之间的一致性。

发明内容

按照本发明，提供了一种按照权利要求1所述的用于在功能系统的系统开发和/或系统验证方面制定可执行规范的计算机实现的方法以及一种按照并列权利要求所述的被设立用于实施该方法的控制单元、一种相对应的按照并列权利要求所述的软件工具（计算机程序）和一种按照并列权利要求所述的机器可读存储介质，在其上存储有该软件工具。其它实施方式在从属权利要求中说明。所有在权利要求书和说明书中针对该方法所提到的进一步的特征和效果也适用于该软件工具和该控制单元，而且反之亦然。

按照第一方面，提供了一种用于在通常任意复杂的功能系统的系统开发和/或系统验证方面以软件工具辅助的方式制定可执行规范的计算机实现的方法，该功能系统可以被设计用于实现对目标设备、尤其是机动车的控制和/或调节的各种功能性。在此，“以软件工具辅助的方式”是指本文中在权利要求书中或者更下文所说明的新型、整体专门用于实现本方法的软件工具，为了实施该方法，该软件工具例如可以在计算机、控制单元或者用于系统开发和/或验证的其它数据处理设备中被安装和运行。

可使用本方法来制定的规范例如是由系统开发者或仿真专家等用户对系统的修改或更改。该规范尤其可以在目标设备的适合的控制单元中实施该系统时产生特定的技术效果，诸如测量、显示和/或更改当前的车速、发动机转速、温度或者机动车或其它目标设备的任意其它物理运行参数。在此，该功能系统包括用于目标设备控制或调节的一个或多个功能。例如，该功能系统可以是驾驶员辅助系统，如车道保持辅助（LKS，Lane KeepingSupport）或自适应巡航控制（ACC，Adaptive Cruise Control），该驾驶员辅助系统可包括如接收和/或确定本车辆和/或在前方行驶或在后方行驶或超车的其它车辆的当前的运动参数以及根据此来确定利用引起相对应地更改的车辆控制所适配的新的运动参数等功能，或者该功能系统可以是能量管理系统，等等。

在此，该规范的“可执行性”是指：利用本方法，可以确保跟踪通过该规范所引起的由用户进行的更改，以保证其与整个系统并且例如与预先确定的对于该规范在目标设备上的可执行性来说所需的技术要求的一致性。为此，本方法包括如下步骤：

- 提供功能系统的至少一个模型视图、尤其是静态功能系统描述和/或以功能性及其依赖性为形式的其它结构性（或者也称为静态）描述和/或动态行为描述（仿真模型）。在此，模型视图是指以对于相对应地经过培训的用户来说能理解的、例如至少部分地图形的表示方式或语言进行的基于模型的系统描述。为了提供相应的模型视图，例如可以使用开头提及的或其它公知的适合于系统开发或仿真的软件工具，如SysML、PREEvision或MATLAB（相应注册商标），按照本发明的本文中所阐述的类型的软件工具例如可以访问这些软件工具；

- 提供选择界面，该选择界面被设计用于由用户在所提供的第一模型视图中选择和/或更改系统部分，该系统部分例如可包括具有相关接口的各个功能或者功能系统的其它建模元素；

- 将在第一模型视图中所选择和/或所更改的系统部分、尤其是所进行的更改和/或其效果和/或在系统其余部分中的依赖性转变并且显示成针对用户的至少一个相应另外的模型视图；

- 提供规范和发布界面，该规范和发布界面被设计用于选择和/或检查和/或进一步适配在至少一个相应另外的模型视图中所显示的更改并且被设计用于由用户来发布在第一模型视图和/或至少一个相应另外的模型视图中进行的对系统的更改；

- 将所发布的对系统的更改自动化地采用到至少一个相应另外的模型视图中并且完成这样被更改的系统。

本文中，术语“用户”不仅可以包括个人而且可以包括多个不同的人，例如：系统开发者，该系统开发者参与静态功能系统描述；仿真专家，该仿真专家受托进行动态行为描述；和/或不同技术领域的专家组，该专家组负责该功能系统所影响的不同车辆域，诸如发动机控制、驾驶员辅助系统、能量供应、空调系统等等。在本方法中，单独的用户或相应不同的用户不仅可以在唯一的模型视图中进行更改，而且在需要时可以在多个不同的模型视图中进行更改，所述模型视图充当上文的第一模型视图或者充当所提到的相应另外的模型视图。

本方法的想法在于由用户在可用的模型视图之一中进行的到在相应另外的模型视图中的同一系统的更改与用户/使用者用于跟踪和保证更改和/或这些更改的评价在其经由该规范和发布界面来发布以在该系统中最终采用之前的一致性的基于工具的支持的在上述转变和显示步骤中实现的语义耦合。本文中，系统的相应被更改的模型元素在不同模型视图之间的语义耦合尤其被理解成这些模型元素的内容上的、内容相关的、逻辑和/或功能耦合，该耦合尤其可以在相应另外的模型视图中充分反映对系统的相应的更改的实际技术效果并且在理想情况下也是如此情况。由此，可以确保一致的跟踪和对通过该规范所引起的更改与整个系统和预先确定的对于该系统在目标设备上的可执行性来说所需的技术要求的一致性的保证。在此，尤其可以实现静态模型视图与动态行为描述的语义耦合。

通过不仅在系统开发的早期阶段（所谓的已知的V模型的左上方部分）而且关于系统验证、也就是说朝向V模型的右上方部分的静态与动态模型视图的这种语义的并且以软件工具辅助的方式的耦合，可以克服到目前为止公知的解决方案的开头所描述的缺陷。所谓的V模型是系统或软件的随着时间的连续的开发和验证阶段以“V”形的直观的图形排列，其中在左侧V分支上的各个开发阶段在右侧V分支中的相应的测试阶段的对面。在此，开始于“V”的左上方部分向下到其尖端排列时间上连续的开发阶段，例如从需求分析（需求工程）经过系统架构的开发和越来越详细的功能和技术规范直至在V尖端处的用于软件和硬件的实现基础，这些开发阶段然后在右侧被验证。

因此，本发明能够实现功能系统的可执行规范（仿真），该规范与静态或动态描述的一致性可以通过相关建模制品、诸如因果链或各个功能或其接口等等的以软件工具辅助的方式的耦合来被保证。本文中所阐述的方法有意识地包括使用者/用户，该使用者/用户可以利用其专业知识来对修改及其依赖性进行合理性检查、检验并且然后进行发布。在此，该规范和发布界面尤其可以支持相应的更改的单独发布、预先确定的具有更改的整个制品集的发布和/或所有更改的总发布。

在本方法中，除了经由选择界面所选择和/或所更改的功能之外，尤其也可以将这些功能的所限定的依赖性、尤其是接口及其描述转移到/转变成相应另外的模型视图并且在其中向用户显示这些功能的所限定的依赖性、尤其是接口及其描述。在此，这些依赖性可以尤其是清晰地被显示/呈现给用户，例如根据关系类型、根据原始和/或目标制品等等来被排序。

尤其是，第一模型视图和至少一个相应另外的模型视图可以包括功能系统的如下模型视图中的两个或更多个：

- 静态功能系统描述，该静态功能系统描述尤其包括至少一个功能因果链，该功能因果链描述了涉及目标设备中的物理功能性的影响和目标参数之间的因果关系；

- 动态行为描述，该动态行为描述尤其包括系统的动态行为的使用仿真软件所产生的仿真；

- 功能架构，在该功能架构中，不同因果链的功能相同部分被聚合并且按照功能从属关系以层次分解来被排列；

- 技术架构，在该技术架构中，不同因果链的技术相同部分被聚合并且按照技术从属关系以层次分解来被排列；

- 需求工程，该需求工程尤其是表示对各个系统部分的技术要求。

在此，例如第一模型视图可以是静态功能系统描述并且相应另外的模型视图之一可以是动态行为描述，或者反之亦然。在此，上述一般性说明的方法步骤尤其可以被实现为使得：

- 用户经由选择界面来选择和/或更改在其静态或动态描述中的整个功能因果链或者该因果链的一个或多个部分；

- 在转变步骤中，从静态描述出发，针对因果链的所选择和/或所更改的部分中的每个部分，在动态行为描述中的功能体利用仿真软件来被自动产生和/或从现有的功能体库存中被挑选并且被显示给用户；

- 其中该规范和发布界面尤其也被设计用于在相应另外的模型视图中、比如在动态行为描述中进行更改，并且被设计用于将这些更改反馈到第一模型视图中或者通常反馈到至少一个结构化模型视图中、比如反馈到静态功能系统描述中和/或反馈到功能架构中，用以检查与系统其余部分有无矛盾。

这里，更改例如可以是功能因果链中的改变的、添加的或删除的功能或接口并且尤其是也相对应地在第一模型视图中并且在相应另外的模型视图中作为“改变”、“添加”或“删除”来被显示给用户。

在此，该规范和发布界面尤其还可以被设计为：向用户提供在要反馈的系统部分的如下选项中的一个或多个选项之间的选择：

- 所有功能和接口；

- 直至由用户经由该规范和发布界面所要限定的细节层面为止的所有功能和所有相关接口或具有这些相关接口的所有主要功能；

- 由用户经由该规范和发布界面所要选择的功能和接口。

在此，这些主要功能例如以本身公知的方式表示对于实现特征（Features）或用例（Use Case）来说所需的并且描述了逻辑或物理关系的功能范围。为了能够做出所提到的选择或者满足底层软件工具或控制单元的相对应的请求，用户例如可以或必须在模型视图之一中辨别：这些功能或接口是系统的主要功能还是次要功能。在此，次要功能可以与主要功能例如以本身公知的方式按如下地区分：

因果链和功能架构的功能考虑通常强制包含主要功能。如果例如执行迭代开发，比如在开头提及的建模平台SPES中所描述的那样，则也可以有意义的是补充次要功能的功能描述。这里，通常也存在不同的解决方案可能性，可以在用户侧借助于功能考虑来理解并且评价这些不同的解决方案可能性。但是重要的是：将这些功能辨别为“次要”，原因在于在考虑特定次要功能的背后，相对应地经过培训的拥有必要的技术知识的设计决策者处在技术架构层面，诸如在使用燃烧发动机或ICE（内燃机（internal combustion engine））时需要高温冷却回路。此外，例如如果使用安全概念（Safety），该安全概念通过冗余来分解安全目标，则也需要冗余的功能/功能性，所述冗余的功能/功能性必须首先被分布到适合的组件上，这进而可以或必须被辨别并且被考虑为次要功能。如果在技术层面的设计决策被更改，则这可能影响这些次要功能。相对应地，记录了技术和功能视角之间的这些依赖关系。

因而，在本方法的这些和所有其它设计方案中，在该规范和发布界面中的检查可以包括用户对与适合于所需的检查或发布地经过培训的组织单元建立联系的请求。这尤其也可以通过在本文中所阐述的类型的软件工具或控制单元中寄存相对应地经过培训的用户以及必要时至少一个代表的电话号码和/或联系地址或者通过实现对用户的适合的联系数据的自动化的查询和提供过程来被支持。

主要或次要功能的上述区别或标识主要基于以下事实：在真实系统中的功能总是需要执行平台，这些功能在该执行平台上运行。该平台使用适合的技术，诸如微控制器、存储模块、功率半导体，但是还有CAN总线、以太网等等。这可以被视为技术的实际任务——表示功能的执行平台。在此，一项技术通常绝不会完美（不足够高性能、可靠、安全……），并且因而必须总是被检查是否遵循预先确定的技术要求（例如功能安全）并且必要时被适配。次要功能的示例是用于组件冷却的热系统。该热系统例如变得必需，以便避免由于效率低而无意地将能量转换成热量的组件的过热。

在一个具体设计方案中，本文中所阐述的类型的方法包括：转变成功能架构；和/或在该规范和发布界面中实现的检查不同因果链的功能相同部分的更改及其匹配。在此，在缺乏匹配的情况下，必要时可以利用对进行在所涉及到的功能中的进一步更改、也就是说对创建这些更改的功能变体的自动请求来向用户通知这一点，利用这些功能变体可以重建匹配。在此，尤其也可以向用户提供以可能的更改选项为形式的用于实现匹配的功能变体的自动建议。例如，在驾驶员辅助系统中，两个不同的因果链的功能相同部分可以是共同的功能，如“探测前方的、落后的和超车的车辆”，其中的一个因果链实现自适应巡航控制（Adaptive Cruise Control，ACC）并且另一个因果链实现车道保持辅助（Lane KeepingSupport，LKS）。

按照另一方面，提供了一种控制单元，该控制单元包括被设立用于实施本文中所阐述的类型的方法的处理器。该控制单元例如可以是适合于系统开发或验证的计算机或计算机网络的一部分。

按照另一方面，提供了一种在更上文在描述该方法时已经提到的软件工具（计算机程序），该软件工具包括指令，在本文中所阐述的类型的控制单元或者其它数据处理装置中执行该软件工具时，这些指令促使该控制单元或该其它数据处理装置实施本文中所阐述的类型的方法。

按照另一方面，提供了一种机器可读存储介质，在其上存储有这种软件工具（计算机程序）。

因此，利用本文中所阐述的类型的方法，尤其可以确定在静态功能系统描述中的因果链（Cause-effect-chain，CEC）与动态行为描述（DVB）之间的语义的并且以软件工具辅助的方式的耦合。为此，不同于开头描述的在系统开发和/或系统验证方面的现有技术，该方法包括建模制品在CEC与DVB之间的双向的、自动化的转变，该转变例如可具有如下步骤：

- 采用整个因果链或因果链的所选择的部分；

- 向用户提供/显示可适配的表示：在相应另外的模型视图中进行了哪些更改并且这在自己的模型视图中有哪些影响；

- 在此例如将如功能或接口等制品标记为添加、改变或删除；

- 在制品被改变的情况下呈现更改；

- 在最终采用更改之前，用户可以借助于该规范和发布界面来执行对这些更改的评价；

- 用户必须根据CEC或DVB来分别发布对被改变的制品的采用；

- 支持单独发布、制品集的发布和所有更改的总发布；

- 只有被发布的更改才被最终采用到相应另外的模型视图中。

在此，除了在CEC或DVB中的更改的影响之外，尤其也可以向用户指明修改后的制品与用于系统开发的基于模型的方法、如开头提及的MBSE（基于模型的系统工程（Model-Based Systems Engineering））的其它模型视图的依赖性。这例如可以是：

- 功能架构；

- 需求工程；和/或

- 技术架构。

在这种情况下，可用的信息和做法类似于上文描述的CEC和DVB耦合。

附图说明

随后，上述方面及其实施方式和具体设计方案依据在随附的附图中呈现的示例来更详细地被阐述。其中：

图1示出了本文中所阐述的类型的用于在功能系统、这里是机动车的驾驶员辅助系统的系统开发和/或系统验证方面制定可执行规范的方法的示例的流程图；

图2a示出了具有三个不同的因果链的静态功能系统描述的示意性示例，该静态功能系统描述用作在按照图1的方法中的第一模型视图；

图2b示出了与图2a相对应的功能架构的示意性示例；

图3a示出了用于表示ACC因果链的静态功能系统描述的另一示意性示例，该静态功能系统描述用作在按照图1的方法中的第一模型视图；

图3b示出了用于开发关于在图3a中由用户选择的功能性的动态行为描述的示意性呈现的仿真框架；

图3c示出了示意性呈现的精细化仿真模型，该仿真模型由用户在按照图3b的所提供的仿真框架中开发；以及

图3d示出了如在图3a中那样具有按照图1的方法反馈并且被显示给用户的对系统的更改的静态功能系统描述。

具体实施方式

比照来说，按照上述第一方面的方法以及按照上述其它方面的相对应的软件工具、控制单元和机器可读存储介质的所有在更上面在说明书中和在随后的权利要求书中提及的各种实施方式、变体和具体设计特征可以在图1至3d中示出的示例中单独地或者以上文提及的组合来被实现。因而，这些实施方式、变体和具体设计特征随后不会再次全部被重复。相同的情况相对应地适用于更上面已经说明的关于在图1至3d中示出的各个特征的术语定义和效果。

图1以流程图示出了本文中所阐述的类型的用于在针对目标设备的功能系统、在本例中是机动车的驾驶员辅助系统的系统开发和/或系统验证方面制定可执行规范的方法。该方法及其可能的具体实施方式中的一些实施方式首先通常主要参考在图2a和图2b中示出的驾驶员辅助系统的静态模型视图M1和M2的示例来被描述，并且然后在另一ACC调节器开发示例中依据图3a至3d来被进一步阐明。

在第一步骤S1中，向用户以静态功能系统描述M1的形式提供在图2a中简化并且示意性呈现的该系统的第一模型视图，该第一模型视图在本例中包括三个不同的因果链W1、W2和W3。在此，第一因果链W1描述了自适应巡航控制（ACC，Adaptive Cruise Control）的简单示例，第二因果链W2描述了横向车道居中（Lateral Lane Centering）的简单示例，并且第三因果链W3描述了高速公路领航员（Highway Pilot）的简单示例。图2b示出了该系统的以与图2a相对应的功能架构M2为形式的补充的另一静态模型视图，这一点在更下面再次被详细探讨。

在汽车应用中的用于自动化驾驶或者用于改善车辆的能效的新的创新功能通常不限于单独的车辆域，而是跨多个车辆域地延伸的复杂因果链。这些复杂因果链例如可以借助于以活动F的序列为形式的活动图及其依赖性经由接口C来被描述，如在图2a中示意性地通过各个块和这些连接线所勾画出的那样，这些活动在本文中也称为功能或功能性。借助于在更上面提及的如SysML（注册商标）等系统开发工具对静态关系的这种因果表示可以在使用同样在更上面提及的如MATLAB/Simulink（注册商标）等专用仿真工具的情况下被扩展动态行为描述M3（未示出，在图3b和3c中示意性勾画出模型元素），该动态行为描述表示上述意义上的另一模型视图。

现在，按照图1的方法能够实现这些静态和动态模型视图M1、M2和M3的各个待指定的模型元素在对共同系统的开发和/或验证期间到该共同系统的新型的、通过本文中所阐述的类型的相对应的软件工具所支持的语义和双向耦合。在此，统一术语“用户”代表所有随后提及的不同的人，这些人在本方法的框架内参与系统开发或验证，如：系统开发者，该系统开发者参与静态功能系统描述M1；仿真专家，该仿真专家受托进行动态行为描述M3；和/或不同技术领域的专家组，该专家组负责该系统所影响的不同车辆域，如发动机控制或能量供应。

在该方法的在上述步骤S1之后的接下来的步骤S2中，向用户提供选择界面，该选择界面被设计用于由用户在第一模型视图、比如图2a中示出的静态功能系统描述M1中选择和/或更改系统部分。因为对因果链进行完整建模由于复杂性或花费而不总是合理，所以用户在此不仅可以选择整个因果链W1、W2或W3而且可以只选择该因果链的部分。

在接下来的步骤S3中，将由用户在步骤S2中在第一模型视图中所选择的或所更改的系统部分自动转变成动态行为描述M3并且针对用户显示该动态行为描述。为此，在本例中，针对所选择的部分在MATLAB/Simulink中自动创建功能体。此外，所选择/所更改的系统部分的在第一模型视图中限定的依赖性、如接口C及其描述被传输（参见图3a）。这些接口可以通过适合的典型规范/属性、比如名称、逻辑物理量、值范围、分辨率、量化、时延要求和/或关于“服务质量（Quality of Service）”等等的其它规范以本身公知的方式来被描述。

对于针对因果链的所选择的部分已经存在仿真模型的情况来说，实现该方法的软件工具向用户提供对哪些功能已经在仿真模型中具有对应物的帮助。此外，向用户指明在功能因果链W1、W2或W3中的改变的、添加的或删除的功能并且显示更改的类型。例如接口是否已经被更改并且这些更改在哪里。

移除的功能在步骤S2和S3中只被表征为“删除”，并且用户可以在接下来的方法过程（步骤S4）中决定他如何处理这种情况。在需要时，该用户可以反映仍需要该功能，并且比如通过让其他专家/用户参与来进行澄清。

在接下来的步骤S4中，向用户提供规范和发布界面，该规范和发布界面能够使用户选择和/或检查和/或进一步适配在动态模型视图以及必要时还有其它模型视图（诸如按照图2b的功能架构M2）中的所显示的元素和更改并且发布所进行的更改。在本例中，功能开发者或仿真专家现在可以基于上述功能体来开发、仿真和评估动态行为描述M3，通常是DAE模型（微分代数方程（Differential Algebraic Equation））。为此，该用户使用已经在静态的第一模型视图中限定的并且在步骤S2中被转移到动态模型视图中的接口并且根据需要来对这些接口进行补充或改变。在此，功能F同样可以被扩展、被添加或者以按照功能架构M2的层次分解来被细化。

在此，该规范和发布界面在本例中也被设计用于将动态行为描述M3的知识自动反馈到例如按照图2a的静态功能系统描述M1和/或自动反馈到按照图2b的功能架构M2，以便保证：在动态模型视图中执行的更改与所涉及到的因果链（在部分因果链的仿真的情况下）的其余功能或与系统其余部分或者车辆其余部分的功能（例如与其它因果链）相适合，也就是说这里没有形成矛盾或冲突。为此，这些更改在本例中被反馈到功能架构M2中并且这样可以由用户来检查有无矛盾。

在此，功能开发者或仿真专家尤其可以选择应该反馈仿真模型的哪些部分。在该规范和发布界面中例如可以支持对于到静态模型视图M1和/或M2中的功能反馈的如下选择可能性：

- 所有功能和接口都被反馈，例如被反馈到功能架构M2中；

- 直至由用户所要限定的细节层面为止的所有功能和所有相关接口或具有这些相关接口的所有主要功能都被反馈；

- 用户所选择的功能和接口被反馈。

如果仿真专家已经在考虑主要和次要功能（参见更上面说明的关于主要和次要功能的区分的细节）的情况下在规范和发布界面中做出了该选择，则该软件工具按照当前的示例方法来执行在MATLAB/Simulink中的包括其接口在内的功能体与在SysML中的因果链描述中的功能之间的对照。在此，例如可以自动检查是添加了还是移除了功能。还可以自动检查功能是否被更改了，也就是说是否存在被更改的功能描述或接口。

在这种情况下，可以通过该方法或相对应的软件工具来实现如下两种情况之间的情况区分；

- 完整的因果链、例如来自图2a中的W1、W2或W3闭合地被反馈。在这种情况下，不需要对该因果链的进一步检查；

- 因果链的部分被反馈。在这种情况下，在SysML侧检查改变的、添加的或删除的功能与因果链其余部分的依赖性并且将这些依赖性呈交给用户用于评价，也就是说在该规范和发布界面中显示评价请求的情况下。在此，用户可以单独地或借助于集体发布来确认/发布每个依赖性或者能够将潜在冲突反映回到动态行为描述。只有被发布的更改才被采用。

在这两种情况下，在SysML侧尤其也可以自动检查形式建模指南、命名约定等等。利用在该规范和发布界面中的适合的显示或评价请求来使用户注意可能的约定违反等等。

在此，被更改的功能可以不仅仅具有在因果链之内的依赖性。因而，在图2b中示例性呈现的功能架构M2可以是在功能、静态或结构化层面的另一基本模型视图。该静态模型视图的目的尤其在于标识因果链与开发功能变体概念的可能性之间的相同部分：

图2a示出了上述三个不同的因果链W1、W2和W3，并且图2b示出了相关的功能架构。该功能架构使功能相同部分聚合，并且根据功能从属关系以层次分解来排列这些功能相同部分。在本例中，因果链W1-W3具有功能相同部分G，该功能相同部分在对应的功能架构中对应于共同的功能，例如“探测前方的、落后的和超车的车辆”。如果在仿真中在这些因果链W1、W2或W3之一中更改该共同的功能，则在当前的方法示例中也可以针对其它两个因果链来实现如下检查：被更改的功能是否可以被使用或者这里是否需要进而能被用于全部三个因果链W1、W2和W3的功能变体。为此，可以在该规范和发布界面中向用户指明这些依赖性。必要时，该用户接着可以通过在功能处的可管理的更改来进而为不同的因果链W1、W2和W3找到共同的解决方案。

但是，在本方法中，以类似的方式不仅可以实现所进行的更改与功能架构M2的依赖性而且可以实现所进行的更改与相邻的开发步骤、如与需求功能或与技术架构的依赖性。在该规范和发布界面中可以利用相对应的评价和/或适配请求来向用户显示所有经建模的依赖性。

为了清楚地呈现可能更多数目的依赖性，这些依赖性例如可以根据关系类型、根据原始和/或目标制品等等来被分组呈现。

由于通常需要来自不同技术领域的多位专家，以便评价可能的后果，所以可以将相对应的组织单元必要时也与其联系数据一起寄存在当前的软件工具中，以便能够实现快速联系。相对应的请求可以在该规范和发布界面中被实现，使得例如在不完成特定类型的更改的情况下就无法发布这些更改。

在下文，按照图1的所描述的方法进一步参考图3a-3d来被阐明，这些图示出了在使用本方法或软件工具的情况下如何基于用于ACC调节器的因果链W4借助于仿真模型、即动态行为描述M3来制定该因果链W4的所选择的元素的开发或进一步规范。比照来说，参考图2a和2b所描述的方法步骤S1-S4也适用于在图3a-3d中示出的示例并且因而不被再次详细重复。

和在上一示例中一样，这里也将在开发时在动态模型视图中获得的知识最终重新反馈到原始因果链W4中，也就是说反馈到按照图3a或图3d的静态功能描述M1中。在此，向用户指明所执行的更改。在此，按照图1的方法或在计算机上运行的相对应的软件工具支持相应“用户”的如下系统开发步骤：

1.系统架构描述了特征ACC的以因果链W4为形式的功能关系，如在图3a中简化呈现的那样。在按照图1的方法的上述步骤S1中，向其他用户提供该特征或系统的所得到的以静态功能系统描述M1为形式的第一模型视图。

2.在该特征之内的功能或功能性F1、在本例中是“计算ACC轨迹”的功能开发者经由在上述方法步骤S2中所提供的选择界面来在上述第一模型视图中选择该功能性F1。

现在，在随后的方法步骤S3中，以软件工具辅助的方式自动生成在图3b中示意性呈现的仿真框架，用于开发关于功能性F1的动态行为描述M3。在此，所有信息被一并自动采用，这些信息包含在按照图3a的第一模型视图的针对功能性F1的因果链描述中，诸如

- 带有其签名的接口C, C1...；

- 对接口C, C1...的定性要求，诸如对低、中等或高数据量的定量说明、时钟时间要求和时延要求；关于功能安全的说明等等；

- 更详细地描述功能性F, F1...的属性，诸如关于功能安全、操作系统、计算能力、存储器等等的说明；

- 功能性F, F1...的文字描述；

- 对应该实现该功能性F, F1...的要求的引用。

3.如图3c中所示，功能开发者现在可以在所提供的仿真框架内开发精细化仿真模型，该精细化仿真模型限定了功能性F1的动态行为。为此，该功能开发者例如引入其它仿真元素，这些其它仿真元素描述了该行为，将该行为与可用的输入和输出参量相关联。该开发者对这些参量进行描述并且基于仿真来限定这些变量的值范围、分辨率、单位、时间要求等等。在需要时，该开发者可以引入其它参量，诸如在本例中说明“对象数据”的输入参量C1到加速度a、速度v和距前方行驶的车辆的距离gap的划分。

4.在需要时，该功能开发者在此不仅对如F1那样的已经包含在因果链W4中的功能性进行精细化，而且引入新功能，诸如在图3d中的新嵌入的功能F3“为ACC准备显示数据”。这也会得到新的依赖性。这样，新引入用于“显示数据”的接口C3。

5.如果动态行为描述M3的完善度已达到了足够的水平，则该功能开发者可以使他的更改以工具辅助的方式、也就是说在上述方法步骤S4中所提供的规范和发布界面中重新被反馈到静态功能模型视图M1中，如图3d示意性呈现的那样。在第一步骤中，所执行的更改在第一功能模型视图M1中只是被辨别，并且必须首先经由该规范和发布界面来被发布，以在特征/系统ACC调节器中最终采用。

6.在此，在本方法中，用户、例如进而系统架构师获得可适配的表示：在相应另外的模型视图中进行了哪些更改并且这在自己的模型视图中有哪些影响。在本例中，这在图3d中在静态功能模型视图M1中被阐明：

- 例如将如功能F, F1...或接口C, C1...等制品标记为添加、改变或删除；

- 在制品被改变的情况下呈现更改；

- 这样，在图3d中，所选择的和/或所更改的原始功能性F1被辨别并且被更改的输入参量C1同样如此。这里，通过解释框E1来向用户呈现被精细化的接口规范；

- 此外，通过按照图3d的显示来向用户指明：该接口更改也影响功能性F2，该功能性必须提供该信息、这里是被更改的输入参量C1。这样，系统架构师可以在发布这些更改之前与功能F2的负责人协调这些更改；

- 功能性F3及其输出参量C3被表征为新的。这里，系统架构师必须评价其必要性并且必要时检查是否已经存在类似的功能性以及是否可以使用相同部分G。无论如何，都应评价对在因果链W4中接下来的功能性F4的影响并且必要时与F4的功能负责人协调这些影响。

7.这能够使系统架构师评价所辨认的更改，在需要时与所涉及到的功能性F1、F2、F3和F4的功能负责人一起评价所辨认的更改。系统架构师现在可以决定他发布哪些更改或者在需要时与功能开发者进行协商并且有意识地不采用更改。

8.在本例中，在该规范和发布界面中支持单独发布、制品集的发布和所有更改的总发布。

9.只有被发布的更改才被最终采用到相应另外的模型视图中。

本文中阐述的类型的方法的应用领域不限于系统开发。例如，静态、功能视角与动态行为描述之间的上述自动化耦合可以被用于在更上面描述的V模型内的各种开发活动。一方面，该方法或实现该方法的软件工具可以被用于开发单独的系统功能或部分功能，原因在于能够通过各个模型视图元素的语义的以软件工具辅助的方式的耦合来实现更改跟踪和控制。因此，该方法有助于对系统设计进行详细解释或开发实现方法。但是，它也同样可以被用于开发自动化的系统或集成测试或者被用于在验证阶段确定适合的刺激和相关的系统反应。

Claims (10)

1.一种用于在针对目标设备、尤其是针对机动车的功能系统的系统开发和/或系统验证方面制定可执行规范的计算机实现的方法，所述方法包括如下步骤：

- 提供（S1）包括用于目标设备控制或调节的一个或多个功能（F、F1、F2、F3、F4）的功能系统的至少一个模型视图；

- 提供（S2）选择界面，所述选择界面被设计用于由用户在所提供的第一模型视图中选择和更改系统部分；

- 将在所述第一模型视图中选择和/或更改的系统部分、尤其是所进行的更改和/或其效果和/或在系统其余部分中的依赖性转变并且显示（S3）在针对所述用户的至少一个相应另外的模型视图中；

- 提供（S4）规范和发布界面，所述规范和发布界面被设计用于选择和/或检查和/或进一步适配在所述至少一个相应另外的模型视图中所显示的系统部分或更改并且被设计用于由所述用户来发布在所述第一模型视图和/或所述至少一个相应另外的模型视图中进行的对所述系统的更改；

- 将所发布的对所述系统的更改自动化地采用到所述至少一个相应另外的模型视图中。

2.根据权利要求1所述的方法，其中除了所选择和/或所更改的功能（F、F1、F2、F3、F4）之外，也将所述功能的所限定的依赖性、尤其是接口（C、C1、C2、C3）及其描述转变成相应另外的模型视图并且在其中向所述用户显示所述功能的所限定的依赖性。

3.根据权利要求1或2所述的方法，其中所述第一模型视图和所述至少一个相应另外的模型视图包括所述功能系统的如下模型视图中的两个或更多个：

- 静态功能系统描述（M1），所述静态功能系统描述尤其包括至少一个功能因果链（W1、W2、W3、W4），所述功能因果链描述了涉及目标设备中的物理功能性的影响和目标参数之间的因果关系；

- 动态行为描述（M3），所述动态行为描述尤其包括所述系统的动态行为的使用仿真软件所产生的仿真；

- 功能架构（M2），在所述功能架构中，不同因果链（W1、W2、W3）的功能相同部分（G）被聚合并且按照功能从属关系以层次分解来被排列；

- 技术架构，在所述技术架构中，不同因果链的技术相同部分被聚合并且按照技术从属关系以层次分解来被排列；

- 需求工程，所述需求工程尤其是表示对各个系统部分的技术要求。

4.根据权利要求3所述的方法，其中

- 所述第一模型视图是静态功能系统描述（M1）并且相应另外的模型视图之一是动态行为描述（M3），或者反之亦然；

- 所述用户经由所述选择界面来在所述静态功能系统描述（M1）中选择和/或更改整个功能因果链（W1；W2；W3；W4）或者所述因果链的一个或多个部分；

- 在转变步骤中，针对所述因果链（W1；W2；W3；W4）的所选择和/或所更改的部分中的每个部分，在所述动态行为描述（M3）中的功能体利用仿真软件来被自动产生和/或从现有的功能体库存中被挑选并且被显示给所述用户；

- 其中所述规范和发布界面优选地也被设计用于在所述动态行为描述（M3）中进行更改，并且被设计用于将所述更改反馈到所述静态功能系统描述（M1）中和/或反馈到所述功能架构（M2）中，用以检查有无矛盾。

5.根据权利要求4所述的方法，其中所述规范和发布界面还被设计为：向所述用户提供在要反馈的系统部分的如下选项之间的选择：

- 所有功能（F、F1、F2、F3、F4）和接口（C、C1、C2、C3）；

- 直至由所述用户经由所述规范和发布界面所要限定的细节层面为止的所有功能（F、F1、F2、F3、F4）和所有相关接口（C、C1、C2、C3）或具有所述相关接口的所有主要功能；

- 由所述用户经由所述规范和发布界面所要选择的功能和接口。

6.根据上述权利要求中任一项所述的方法，所述方法包括转变成所述功能架构（M2）和/或在所述规范和发布界面中所包括的对不同因果链（W1、W2、W3）的功能相同部分（G）的更改的检查以及在缺乏匹配的情况下包括以对关于匹配的功能变体的更改选项的可选的提供来向所述用户显示。

7.根据上述权利要求中任一项所述的方法，其中在所述规范和发布界面中的检查包括所述用户对与适合于所需的检查或发布的组织单元建立联系的请求。

8.一种控制单元，所述控制单元包括处理器，该处理器被设立为实施根据权利要求1至7中任一项所述的方法。

9.一种软件工具，所述软件工具包括指令，在控制单元或数据处理装置中执行所述软件工具时，所述指令促使所述控制单元或所述数据处理装置实施根据权利要求1至7中任一项所述的方法。

10.一种机器可读存储介质，在其上存储有根据权利要求9所述的软件工具。

Images