CN115687071A - 嵌入式软件系统的成分验证 - Google Patents

Abstract

用于静态检查软件系统的方法，软件系统分解为多个软件单元，在软件单元之间存在接口，每个接口连接第一软件单元和第二软件单元，使得第一软件单元具有对于第二软件单元充当输入变量的输出变量；该方法包括接收接口的上下文信息，上下文信息分别包括第一软件单元的输出变量的后置条件和/或第二软件单元的输入变量的先决条件；接收对第三软件单元的选择，使得产生软件系统向第三软件单元和第三软件单元的补集的相关联替代分解，其中第三软件单元和补集通过替代接口连接，使得补集具有对于第三软件单元充当输入变量的输出变量；至少基于上下文信息，为补集的每个输出变量选择后置条件；以及检查所选择的后置条件是否可以通过第三软件单元前向传播。

Description

嵌入式软件系统的成分验证

背景技术

软件可能包含错误，特别是从具有一定的复杂性开始。一类错误例如由软件运行时期间出现的运行时错误形成。运行时错误可能导致软件崩溃或导致软件行为不正确。软件的不正确行为有时在开发和/或测试期间无法被发现，并且以后在使用时导致软件崩溃。

在软件、特别是与安全相关的软件中不应出现运行时错误。但是，如果在执行软件时出现运行时错误，则可能会不可避免地中断软件的执行。然后不能再提供由软件执行引起的软件功能性（例如，如果安全架构中的冗余未拦截错误结果）。如果运行时错误导致软件行为不正确，则软件的功能性同样可能被破坏或取消。运行时错误例如可能通过以下方式出现，即不符合软件进行编程所使用的编程语言的隐含假设。例如，在除法中除数不允许为零，或者不允许访问所定义的数组大小之外的数组元素。如果无论如何都这样做，则通常会导致未定义的行为、不正确的结果和/或软件崩溃。

软件可以被设计为监视、控制和/或调节技术系统，特别是例如驾驶系统。执行软件时运行时错误的影响（例如所述错误结果）通常可能取决于许多因素（系统、环境、应用情况、开放的上下文……）。在不好的情况下，所述影响（例如所述错误结果）可能包括事故、损坏、伤害和/或死亡结果。例如，除以零的运行时错误可能导致软件执行遭到中止，然后该执行不能再完成其实际任务（例如操控制动器或触发安全气囊）。另一个示例是用不正确的数据覆盖存储区域，例如当写入超出数组边界以及因此无意地改变了碰巧在那里的其他变量时，这可能导致不正确的行为或甚至导致崩溃。对于技术系统的用户和/或环境而言，技术系统可以是安全关键的。在这种技术系统中使用的软件同样可以是安全关键的。然而，软件也可以与技术系统无关地是安全关键的。

因此需要采取可以/应当确保软件中没有错误的措施，特别是在安全关键软件的情况下。为此，经常对软件进行广泛的测试。但是，测试只能显示错误的存在而不能证明错误不存在，因为测试总是只能检查特定的个体配置或个体场景（“抽查”），而不能检查软件在所有配置/场景中的正确行为。

存在对软件进行形式验证的方案，这些方案可以形式上证明所述软件是无错误的。这些方案通常需要形式规范，而这种规范通常不存在并且创建起来可能很复杂。但是，形式规范一般可用于运行时错误类别。用于形式验证的方案包括抽象解释和模型检查。在抽象解释中，程序的指令在抽象域上执行。因此，在适当选择抽象域的情况下可以确定程序行为的良好过度近似。相反，模型检查相对于形式规范来检查程序模型，例如在时间逻辑上。有界模型检查（BMC）是模型检查的一种特殊变体，其只在给定限制（Bound）内做出有效说明。BMC与许多模型检查方案相比可以更好自动化地使用。

存在多种商业工具（英语：tool）可以使用这些方法检查软件的运行时错误（例如AbsInt的Astrée和MathWorks的Polyspace CodeProver），以及一些来自学术领域的工具（例如牛津大学的CBMC）。然而，所有这些工具都存在以下问题，即这些工具要么无法扩展到大型软件系统，要么提供许多虚假肯定的结果。后者通常是由于这些工具为了免于忽略任何错误（“健全性”）而设计得保守，这在原则上对安全相关系统可能有意义。然而，要分析的系统越复杂，分析就越不精确，并且可能显示越多的虚假肯定的错误消息。虚假肯定的错误消息可以例如是实际上可能永远不会出现的错误的消息。这尤其是因为随着系统变得越来越复杂，并非所有信息都可以准确保存（即必须对信息进行汇编或抽象），否则存储器消耗和运行时间将以指数方式增加，然后无法再进行错误分析。

相反，如果单独分析系统的各个部分，则缺少关于其上下文的信息，这同样会导致许多虚假肯定的消息。对于许多虚假肯定的消息，特别是在必须手动评估这些消息时，在此会产生巨大且通常难以管理的耗费，这使得实际上不可能在工业环境中使用这些工具。

软件通常是一个软件系统，其包括多个可以通过接口相互交互的软件单元。软件单元的接口除了函数调用和相关联的参数外，还可以由返回值和可能的共享存储器组成。例如，软件系统可以包括通过接口相互连接的软件单元A和软件单元B。此外，例如软件系统可以包括软件单元C和D，它们分别通过接口与软件单元A连接。对软件单元A的检查现在例如传统上可以要么隔离地进行，要么在整个软件系统的上下文中进行。

在第一种情况下，接口对所有方面（例如对软件单元B、C和D）都是开放的，并且对上下文一无所知。这里只需要基于接口的语法来推断出可能的使用形式，但是这可以包括许多永远不会出现的使用可能性。这又通常导致许多虚假肯定的（错误）消息。

在第二种情况下，对整个软件系统一起检查。因此存在完整的上下文信息。然而，真实情况的软件系统很快变得庞大，以至于检查只能非常肤浅地进行，由此限制了分析的精确度。例如，循环无法得到更准确的分析并且必须被过度近似。这通常也会导致许多虚假肯定的（错误）消息。

更准确地定义函数或模块的接口的合约（Bertrand Meyer于1986年首次为Eiffel描述，英语：contracts；用于基于合约的编程）是已知的。合约包括必须得到满足才能使功能/模块正确运行的特殊先决条件，以及由功能/模块随后断言的后置条件。在研究工作中试图将合约集成到编程语言中并进行静态检查（例如C#的Spec#或Java的JML，C++2x中的合约属性），但不是从嵌入式软件系统的成分验证的角度。在实践中，合约到目前为止只在运行时（断言）检查，而不是被静态检查。

开发人员可以例如手动编写合约。这些合约尤其可以由先决条件（英语：preconditions）和后置条件（英语：postconditions）组成。先决条件在此描述了对软件（组件）（例如功能、模块、类、子系统）的输入变量或状态的附加限制，必须满足这些限制才能使软件（组件）正确工作。后置条件对应地描述了组件执行后系统的状态（例如组件的状态或函数的可能返回值）。理想情况下，鲁棒的软件应该不需要先决条件。然而，出于性能、算法兼容性和对其他组件的依赖性的原因，经常无法将软件设计为完全鲁棒的。为了保护这些组件并由此保证正确的整体行为，可以使用合约。

对于日常工业使用，形式合约的手动编写——即为每个单独的软件组件创建正确的先决条件和后置条件——仅适用于少数小型、极其安全关键的系统。工作量通常太高而无法广泛使用。此外，软件大多基于高比例的所谓“遗留代码”（例如：已经存在的（即旧的）编程代码，例如来自以前的项目），这些代码不经常被开发人员再次处理和/或进一步开发。在实践中，为这些组件事后手动添加先决条件是困难和/或耗时的，因此通常是不可行的，特别是如果软件开发人员在此期间例如改变了工作，和/或软件开发人员对“遗留代码”的额外隐含知识不再可用。因此有利的是，能够从编程代码中自动导出合约（先决条件和/或后置条件）。

发明内容

本公开的第一一般方面涉及一种用于对软件系统进行静态检查的计算机实现的方法，所述软件系统分解为多个软件单元。在所述软件单元之间存在一个或多个接口，其中每个接口至少连接所述多个软件单元中的相应的第一软件单元和相应的第二软件单元，使得相应的第一软件单元具有对于相应的第二软件单元充当至少一个输入变量的至少一个输出变量。该方法包括接收至少一个接口的上下文信息，其中所述上下文信息分别包括相应的第一软件单元的至少一个输出变量的至少一个后置条件和/或相应的第二软件单元的至少一个输入变量的至少一个先决条件；接收从所述多个软件单元中对第三软件单元的选择，使得产生所述软件系统向所述第三软件单元和所述第三软件单元的补集的相关联替代分解，其中所述第三软件单元和所述补集形成所述软件系统并且至少通过替代接口连接，使得所述补集具有对于所述第三软件单元充当输入变量的至少一个输出变量；至少基于为所述至少一个接口接收的上下文信息，为所述补集的充当所述第三软件单元的输入变量的每个输出变量选择至少一个后置条件；以及检查所选择的一个或多个后置条件是否可以在形式验证方面通过所述第三软件单元前向传播。

本公开的第二一般方面涉及一种软件单元，其作为第三软件单元按照根据第一一般方面（或其实施方式）的用于对软件系统进行静态检查的计算机实现的方法来检查和/或释放。

本公开的第三一般方面涉及一种软件系统，在所述软件系统中多个软件单元中的每个软件单元作为相应的第三软件单元按照根据第一一般方面（或其实施方式）的用于对软件系统进行静态检查的计算机实现的方法来检查和/或释放。

本公开的第四一般方面涉及一种方法，该方法包括提供根据第三一般方面（或其实施方式）的软件系统并且可选地使用该软件系统。

在本公开中提出的根据第一一般方面（或其实施方式）的方法使得能够静态检查软件系统的软件单元并因此静态检查整个软件系统的运行时错误。例如，由此用于监视、控制和/或调节技术系统（例如车辆）的嵌入式系统（“嵌入式软件”）可以针对运行时错误得到验证。除了局部错误之外，静态检查还可以发现集成错误，其中集成错误不可能出现在软件单元内，而是出现在软件单元之间的接口处。特别是在具有一定复杂性的软件系统的情况下，例如作为用于控制技术系统（例如车辆）的嵌入式系统，早期可检查性通常在开发期间而不是在集成之后才被证明是有利的，因为那时可以早期并且特别是可以及时纠正错误并且可以改进功能性。例如，从具有一定复杂性开始，软件系统的软件单元通常在产品开发过程中由不同的开发人员或多或少地同时开发（和管理）。与软件系统的所有其他软件单元的当前版本交互的单个软件单元的版本的完整测试可能很复杂，并且由于逻辑原因甚至是不可能的。通过例如软件系统的软件单元之间的预先约定的行为（例如，具有接口的输入变量的先决条件和/或接口的输出变量的后置条件的合约），可以在根据第一一般方面（或其实施方式）的方法中为单个软件单元（即对于第三软件单元）抽象出所有其他软件单元的期望或计划的行为。由此可以独立于其他软件单元的开发状态来检查单个软件单元。可以在开发过程的不同时刻对各个软件单元（即第三软件单元）重复此过程。因此，该方法可以逐步得到应用。此外，还可以针对软件系统的每个其他软件单元重复该过程。由此可以验证整个软件系统。

在本公开中提出的根据第一一般方面（或其实施方式）方法的其他优点可以在于：可以产生尽可能少的虚假肯定的错误消息并且该方法还可以扩展到大型软件系统。这可以通过以下方式实现，即不将待检查的软件单元（即第三软件单元）与其他软件单元（即补集）完全隔离，使得与其他软件单元的接口处（即替代接口处）的先决条件和/或后置条件得以保留和考虑。此外，也可以分析由异构组件组成的软件系统。这种异质性例如可能由不同的编程语言、所提供的黑盒组件、人工智能组件等导致。因此，根据第一一般方面（或其实施方式）的方法预定用于复杂的和/或安全相关的软件系统，例如用于监视、控制和/或调节技术系统（例如车辆）的嵌入式系统。

可以在考虑各个软件单元的计划的使用上下文的情况下对各个软件单元隔离地进行检查，例如在它们的开发期间就已经进行，并且特别是——在实践中经常发生的情况下——在不是软件系统的所有软件单元都可用的情况下。到目前为止可以在使用上下文中进行检查，例如在开发结束时才进行——在所有单元集成之后。这是不利的，因为越晚发现错误，消除错误的成本就越高。此外，在更改之后（例如在纠正之后）只需重新检查所涉及的组件，而不需要再次检查整个软件系统。这特别是在软件单元具有不同职责和/或释放模态的情况下是有利的。通过根据第一一般方面（或其实施方式）的方法可以缩短发现错误和消除错误并且必要时重新释放测试之间的时间，并由此改进软件系统的质量。

软件单元的隔离检查的结果可以用于简化和/或完全替代以后的集成分析，并且从而伴随开发并且特别是在开发的早期阶段识别集成错误。例如，集成分析只能还由检查所有合约之间的兼容性组成，因此比迄今为止的明显更快。在当前工具的情况下，该检查完全可以持续数天。

由于每次仅检查单个软件单元，因此根据第一一般方面（或其实施方式）的方法能够在短时间内执行检查而不会遇到缩放问题。

为了检查单个单元，可以非常精确地进行分析，因为不会出现缩放问题。因此可以最小化虚假肯定的错误消息的数量，并且可以减少针对这些消息的手动检查耗费。

通过组件的合约来对组件进行抽象，使得还可以超越编程语言的界限进行分析。此外，还可以引入其内容不作为源代码可用的组件（例如所提供的软件）。

附图说明

图1示意性地示出了用于静态检查软件系统的计算机实现的方法。

图2a示意性地示出了具有至少两个通过接口相互连接的软件单元的示例性软件系统。

图2b示意性地示出了具有六个软件单元的示例性软件系统，其中一些软件单元通过接口相互连接。

图2c示意性地示出了具有通过接口相互连接的第三软件单元及其补集的替代分解。

图3示出了用于静态检查软件系统的计算机实现的方法的示例性实施方式。

图4示意性地图示了用于静态检查软件系统的（替代的）另一计算机实现的方法。

具体实施方式

图1中示意性示出的计算机实现的方法100旨在对软件系统的软件单元进行静态检查和/或对软件系统进行静态检查。软件系统10例如可以是嵌入式系统（英语：embeddedsystem）和/或被设计为在嵌入式系统中实现（这里在计算机系统的意义上）。软件系统10可以被设计为监视、控制和/或调节技术系统，特别是驾驶系统。所述驾驶系统可以是例如控制设备软件，例如用于发动机控制。所述技术系统，特别是所述驾驶系统，可以是安全关键的。嵌入式系统可以是集成到技术上下文中的计算机系统——例如包括处理器、存储器和输入或输出设备。例如，所述计算机系统可以在更大的技术系统、特别是更大的机电系统中具有专用的功能性。

首先，公开了一种用于对软件系统10进行静态检查的计算机实现的方法100，该软件系统10分解为多个软件单元20、21、22、23、24、25。这种分解在图2a-b中示例性地示出。多个软件单元例如可以包括≥2、≥3、≥4、≥5、≥10、≥50、≥100、≥1e3、≥1e4个软件单元。与动态检查不同，静态检查不依赖于使用具体值执行软件单元。这可能是一个优点，因为具体执行需要具体输入，而具体输入通常只能涵盖抽查测试。在软件单元20-25之间存在一个或多个接口。这并不意味着每个软件单元都通过接口与每个其他软件单元连接。不排除软件单元不通过接口与其他软件单元之一连接的相当微不足道的情况，但由于缺乏与其他软件单元的交互，因此不是特别感兴趣的。这同样适用于以下软件单元组，其中没有软件单元通过接口与其余的软件单元组连接。例如在图2b中，软件单元24不是通过一个接口连接到软件单元25，而是通过多个接口和软件单元20、21、22、23连接到软件单元25。在软件系统10的分解中，可以存在至少一个接口。每个接口至少连接多个软件单元20-25中的相应的第一软件单元和相应的第二软件单元，使得相应的第一软件单元20、21、22、23、24具有至少一个输出变量40，所述输出变量对于相应的第二软件单元20、21、22、23、25充当至少一个输入变量50。术语相应的第一/第二软件单元涉及（具体的）接口。例如，图2b中的软件单元21是用于软件单元21和软件单元20之间的接口的第一软件单元。对于该接口，软件单元20是第二软件单元。另一方面，图2b中的软件单元21也是用于软件单元20和软件单元23之间的接口的第一软件单元，等等。相应的第二软件单元可以（参见“接口至少连接......使得……”）继续具有至少一个输出变量，所述输出变量对于相应的第一软件单元充当至少一个输入变量。例如在图2b中，在软件单元23和25之间示出了这样的接口。圆环闭合可以是一致的，使得一个或多个输出变量取决于来自先前计算步骤（例如中断）的一个或多个输入变量。此外，接口可以包括多个输入变量和/或输出变量，例如参见图2b中的软件单元20、21、22。此外，每个软件单元可以具有一个或多个全局输入变量和/或一个或多个全局输出变量。这种全局输入变量和输出变量在图2a-c中通过虚线箭头示出。因此它们同时是软件系统的输入变量和/或输出变量。

方法100包括接收120至少一个接口的上下文信息，其中所述上下文信息分别包括相应的第一软件单元的至少一个输出变量40的至少一个后置条件和/或相应的第二软件单元的至少一个输入变量50的至少一个先决条件。例如，所述上下文信息可以从每个接口的合约中导出。此外，方法100可以包括接收至少一个全局输入变量的至少一个（全局）后置条件。这样的（全局）后置条件可以例如从规范、特别是传感器规范中提供，或作为包括软件系统10的更大的软件系统的后置条件来提供。此外，方法100可以包括接收至少一个全局输出变量的至少一个先决条件。这样的（全局）先决条件又可以例如从规范、特别是驱动器规范中提供或者作为包括该软件系统的更大的软件系统的先决条件来提供。

方法100还包括接收130从多个软件单元20-25中对第三软件单元20的选择，使得产生131相关联的（即，属于第三软件单元20）软件系统10向第三软件单元20和第三软件单元20的（数学上：该）补集30的替代分解，其中第三软件单元20和补集30形成软件系统10并且至少通过替代接口连接，使得补集30具有至少一个输出变量40，所述输出变量对于第三软件单元20充当输入变量50。换言之，在替代分解中存在替代接口。第三软件单元20是应当检查的软件单元。例如在图2b-c中，接收/选择130软件单元20，并且形成软件系统10的相关联的替代分解，其方式是软件单元21、22、23、24、25形成补集30，该补集通过替代接口与软件单元20连接。如上面已经解释的，第三软件单元没有通过替代接口与补集30连接的情况对于静态检查不感兴趣。替代接口的存在隐含意味着存在至少一个接口。相反，在软件系统10的分解中存在至少一个接口允许至少一个替代分解，并且特别是允许接收/选择130至少一个第三软件单元20。属于第三软件单元的替代分解可能是虚构的，即没有必要将其他软件单元物理地（例如在一个模块中等）统一成补集。相反，补集通过其（相关的）上下文信息来得到抽象可能就足够了（参见下一步骤140）。这个过程也可以称为删除第三软件单元。术语“第三软件单元”并不意味着必须有至少三个软件单元。事实上，例如也在图2a中可以接收/选择130软件单元20作为第三软件单元，并且可以产生131具有由软件单元24组成的补集30的相关联替代分解。接收130可以包括例如通过编程环境和/或集成环境的用户接口进行选择，并且因此依赖于用户（例如，程序员）的输入。替代地，接收130可以是自动选择。例如，自动选择可以是通过软件系统10的分解的多个（例如，仅在自己的职责范围内的那些）和/或所有（第三方）软件单元的循环中的子步骤。在这样的选择中可以隐含地包含关于是否可以使用替代接口进行替代分解的检查。因此在这样的循环中，可以静态地检查软件系统10的每个软件单元以及因此静态地检查整个软件系统10。

方法100还包括至少基于为至少一个接口接收120的上下文信息，为补集30的充当第三软件单元20的输入变量50的每个输出变量40选择140至少一个后置条件。此外，方法100可以包括为至少一个全局输入变量选择至少一个（全局）后置条件。方法100可以包括为第三软件单元20的每个输入变量（全局或局部）选择至少一个后置条件（全局或局部）。非全局后置条件——即没有分配给全局输入变量而是分配给软件系统的软件单元的输出变量的后置条件——可以称为局部后置条件。非全局先决条件——即没有分配给全局输出变量而是分配给软件系统的软件单元的输入变量的先决条件——可以称为局部输入条件。所述选择（例如140）可以直接由软件系统向软件单元和接口的分解的拓扑结构得出，或者由软件系统向第三软件单元及其补集的替代分解的拓扑结构得出。

方法100还包括检查150所选择140的一个或多个后置条件（和/或所选择的一个或多个全局后置条件）是否可以在形式验证（例如无错误）方面通过第三软件单元20前向传播151。所述形式验证例如可以在于：不允许出现运行时错误。然后检查150可以是检查所选择的后置条件（全局和/或局部）是否可以从第三软件单元20的输入变量前向传播到第三软件单元20的至少一端而不可能出现运行时错误。如果可能出现运行时错误，则检查150是否定的。否则，检查150是肯定的（即，成功）。换言之，前向传播151开始，并且在肯定的情况下一直穿越到第三软件单元20的至少一端。相反在否定的情况下，前向传播151被中止并且不能达到第三软件单元20的至少一端。与图1中的图示相反，例如可以通过用户接口向用户回放否定结果（与肯定结果一样）。替代地或附加地，例如检查150可以包括检查在从第三软件单元20的输入变量前向传播到第三软件单元20的至少一端时是否可以符合第三软件单元20中的所有断言。形式验证的其他标准是可能的。图1中的步骤顺序是示例性的。例如，步骤120也可以在步骤130之后进行并且仍然与步骤140重合。如果应当在多个第三软件单元上进行循环，则所示序列可能是有利的。因为这样一来步骤120只需要进行一次并且不需要重复。

第三软件单元20和补集30至少也可以连接，使得第三软件单元20具有充当补集30的输入变量51（例如，用于下一个计算步骤）的至少一个输出变量41，如图2c中示例性示出的。方法100还可以包括至少基于至少一个上下文信息（即，另外的接口的上下文信息）为补集30的通过第三软件单元20的输出变量41提供的每个输入变量51选择141至少一个先决条件。此外，方法100可以包括为至少一个全局输出变量选择至少一个（全局）先决条件。方法100可以包括为第三软件单元20的每个输出变量（全局或局部）选择至少一个先决条件（全局或局部）。所述选择（例如141）可以直接由软件系统向软件单元和接口的分解的拓扑结构得出，或者由软件系统向第三软件单元及其补集的替代分解的拓扑结构得出。

方法100还可以包括检查152一个或多个所选择140的并且在形式验证方面通过软件单元前向传播151的后置条件是否满足为补集30的每个输入变量51选择141的一个或多个先决条件。替代地或附加地，方法100可以包括检查所选择（例如140）的和在形式验证方面通过软件单元前向传播（例如151）的全局和/或局部后置条件是否满足补集的每个输入变量51的一个或多个所选择141的先决条件和/或一个或多个所选择的全局先决条件。检查152可以是否定或肯定（即成功）的。与图1中的图示相反，例如可以通过用户接口向用户回放否定结果（与肯定结果一样）。

方法100可以被设计为识别软件单元20-25和/或软件系统10中的运行时错误。事实上，否定的检查结果例如可以通过编程环境和/或集成环境的用户接口反馈给用户。由此，用户可以例如启动创建补救并且在重新检查150、152时引起肯定检查结果的措施。引起肯定检查结果对于第三软件单元20和/或整个软件系统10的释放可能是必要的。补救可以例如通过以下方式创建，即改变和/或纠正第三软件单元的编程代码，并且例如由此避免发现运行时错误。

一个或多个所产生140的后置条件和/或一个或多个所选择的全局后置条件通过第三软件单元20的前向传播151可以基于抽象计算。抽象计算可以是完全或部分分析的（即非具体的）。因此，抽象计算不必依赖于具体输入。与例如仅涵盖抽查测试的具体输入不同——因为并非所有具体的输入配置都可以（在预给定时间内）实现，分析计算还可以检测和评估输入的值范围（也称为域）。通过抽象计算可以减少计算时间。例如，在除法时可以在编程代码中（在特定情况下）分析地计算何时除数为零。然后可以由此确定输入上的一个或多个条件，所述条件防止发生除以零。替代地或附加地，前向传播151可以基于具体计算。例如，前向传播151有时可以基于符合Monte Carlo的概率输入（例如，针对一个或多个全局输出变量）。由此也可以至少在概率上一起考虑例如外部影响，特别是传感器影响。

方法100还可以包括：如果关于一个或多个所选择140的后置条件是否可以在形式验证方面通过第三软件单元前向传播151的检查150是肯定的，则释放160第三软件单元20。

方法100可以进一步包括：如果关于一个或多个所选择140的并且在形式验证方面通过软件单元前向传播151的后置条件是否满足为补集30的每个输入变量51选择141的一个或多个先决条件的检查152是肯定的，则释放161第三软件单元20。

这样的释放160、161例如可以在产品责任的情况下用作证明。

此外，可以选择多个软件单元20-25中的至少一个另外的第三软件单元21并且类似于第三软件单元20来检查150、152和/或释放160、161至少一个另外的第三软件单元21。由此，可以实现经由多个和/或所有待检查的软件单元的循环。因此，可以检查并最终释放部分和/或整个软件系统10。这种可选的循环在图1中通过从步骤160/161到步骤130/131的虚线箭头示意性地示出。

方法100可以包括将软件系统10分解110为多个软件单元20-25。分解110可以是自动化地进行，例如按照存储、文件、功能、模块、类和/或子系统的结构进行。替代地或附加地，较大的部分例如可以通过代码聚类分解为较小的软件单元。替代地或附加地，将软件系统10分解110为多个软件单元20-25可以基于用户（例如程序员和/或负责确认/验证的人）经由编程环境和/或集成环境的用户接口的至少一个输入。如图1中示意性所示，所述分解可以在步骤120和/或经由多个第三软件单元的可能循环之前进行。

接收120第一和第二软件单元之间的接口的上下文信息可以包括从注释、特别是从规范中读取121a第一软件单元的至少一个输出变量40的至少一个后置条件和/或读取121b第二软件单元的至少一个输入变量50的至少一个先决条件。例如，如果软件系统10的分解已经存在或已经设定，则可能是这种情况。

替代地或附加地，接收120第一和第二软件单元之间的接口的上下文信息可以包括为第一软件单元的至少一个输出变量40产生122a至少一个后置条件和/或为第二软件单元的至少一个输入变量50产生122b至少一个先决条件（例如通过反向传播和抽象计算）。为第一软件单元的至少一个输出变量40产生122a至少一个后置条件可以基于第一软件单元的至少一个另外的输入变量的至少一个另外的先决条件。为第二软件单元的至少一个输入变量50产生122b至少一个先决条件可以基于至少一个另外的输出变量的至少一个另外的后置条件。

“形式验证”可以理解为借助于诸如抽象解释或有界模型检查的自动证明方法，在形式规范方面对软件单元或软件系统的正确性或不正确性进行形式证明。

根据本公开中提出的方法100、200，形式验证方法可以应用于大型软件系统，其方式是将软件系统分解/切割为小的软件单元（例如子系统、组件、模块、功能）并且通过上下文信息（来自所谓的合约）使所产生的（开放的）与从属软件单元的接口更为丰富。所述上下文信息可以由必须适用于软件单元才能无错误地执行该软件单元的至少一个先决条件以及在一个或多个先决条件得到满足时由软件单元在执行后断言的至少一个后置条件组成。这些信息可以在开发过程中已经手动注释，或者也可以通过代码分析从代码中自动获取。然后可以将待分析的软件单元的上下文信息以及从属软件单元的对应信息用于分析该软件单元。由于较小的软件单元和/或接口处的附加上下文知识，可以提高该分析的精度，从而可以减少虚假肯定的错误消息。如果预先合适地制备了待检查的编程代码，则业已存在的形式验证工具（例如上面提到的那些）可以用于对更小的软件单元进行实际检查。

图3示出了用于对软件系统进行静态检查的计算机实现的方法的示例性实施方式。

在第一步骤中，这里可以将软件系统分解为更小的软件单元（图3中简写为：单元），然后可以向每个软件单元单独地补充从属软件单元的合约信息，然后对该软件单元进行形式验证。因此，如果所有软件单元都得到成功验证，则（整个）软件系统10也得到验证。

可以基于自然存在的结构（如功能、模块、类和子系统）将软件系统分解为更小的软件单元。替代地，也可以通过形成其他结构来进行所述分解，所述其他结构例如在接口宽度方面进行了优化（聚类）。

可以从软件系统中分别切割出待检查的软件单元。它们的从属软件单元（例如，调用函数、全局变量等）可以替换为它们的合约（参见图2c）。由此可以以抽象的形式考虑从属软件单元的行为，这导致可以更精确地分析待检查的软件单元（例如第三软件单元20）的行为并且可以减少虚假肯定的（错误）消息的数量。

例如，所使用的软件单元24、30可以提供在待检查的软件单元20中用作除数的值。如果软件单元24、30的合约断言所述软件单元总是提供非零值，则可以在软件单元20中的对应位置排除除以零。如果缺少该知识，则所述分析将报告虚假肯定的错误，然后只能通过手动检查来排除该错误。

此外，可以执行集成检查（与例如方法200中一样）：

符合所使用的软件单元的（合约的）先决条件可以直接在检查软件单元的范围中进行。为此，可以在所使用的软件单元的接口处检查所传输的数据是否符合其合约。

替代地，也可以在下游进行集成测试。为此，必须收集、汇总相应接口上存在的数据，然后对照相应目标软件单元的合约（例如具有输入变量的合约）检查所述数据。如果软件单元或合约发生更改，则只需要重新检查对应的软件单元及其邻居。系统的其余部分不受影响。

一种可能的实施使用现有的检查工具来检查软件单元。然后使用这些工具支持的语言手段来实施合约。为此使用用于设置值范围或其他关于变量的知识的相应指令以及用于检查条件的指令（例如assert（））。由此对于待检查的软件单元所使用的每个软件单元，可以在其调用时检查其先决条件的有效性（例如断言先决条件），并确保其后置条件的有效性（例如通过对应地设置返回值）。为此于是不再需要对所使用软件单元的实际内容进行分析——通过合约对该软件单元抽象。

另一种可能的实施是实现形式验证，使得所述形式验证可以直接处理软件系统的编程代码以及合约信息，并在分析时考虑它们。

公开了至少一个计算机程序，其被设计为执行用于对软件系统进行静态检查的计算机实现的方法100。所述计算机程序例如可以以可解释的形式或编译形式存在。所述计算机程序可以（也部分地）例如作为位序列或字节序列加载到控制设备或计算机的RAM中以用于执行，其中计算机也可以充当服务器。

还公开了一种存储和/或包含所述至少一个计算机程序的计算机可读介质或信号。所述介质例如可以包括其中存储所述信号的RAM、ROM、EPROM、...之一。

还公开了一种被设计为执行所述计算机程序的计算机系统。特别地，所述计算机系统可以包括至少一个处理器和至少一个工作存储器。此外，所述计算机系统可以包括存储器。所述计算机系统可以扩展到包括服务器的系统。

还公开了软件单元，其作为第三软件单元20根据用于对软件系统10进行静态检查的计算机实现的方法100来检查150、152和/或释放160、161。

还公开了软件系统10，在所述软件系统中多个软件单元20-25中的每个软件单元作为相应的第三软件单元20、21根据用于对软件系统10进行静态检查的计算机实现的方法100来检查150、152和/或释放160、161。

还公开了方法300，该方法包括提供310软件系统10，在所述软件系统中多个软件单元20-25中的每个软件单元作为相应的第三软件单元20、21根据用于对软件系统10进行静态检查的计算机实现的方法100来检查150、152和/或释放160、161。方法300可以包括使用320软件系统10。方法300例如在运行中使用并且可以用于320控制驾驶系统。

还公开了用于对软件系统10进行静态检查的另一种计算机实现的方法200，软件系统10被分解为多个软件单元20-25，其中在软件单元20-25之间存在一个或多个接口，其中每个接口至少连接多个软件单元20-25中的相应的第一软件单元和相应的第二软件单元，使得相应的第一软件单元具有至少一个输出变量40，所述输出变量对于相应的第二软件单元充当至少一个输入变量。

方法200可以包括：对于相应的第一软件单元和相应的第二软件单元之间的每个接口，接收220用于该接口的接口标准，其中每个接口标准包括针对相应的第一软件单元的至少一个输出变量40的至少一个后置条件和针对相应的第二软件单元的至少一个输入变量50的至少一个先决条件，并且当所有先决条件都由相关联的后置条件满足时得到满足。

方法200还可以包括：对于相应的第一软件单元和相应的第二软件单元之间的每个接口，检查230是否满足用于该接口的相应接口标准。

还公开了用于对软件系统10进行静态检查的替代的另一种计算机实现的方法200，所述软件系统被分解为多个软件单元20-25，其中在软件单元20-25之间存在一个或多个接口，其中每个接口至少连接多个软件单元20-25中的相应的第一软件单元和相应的第二软件单元，使得相应的第一软件单元具有至少一个输出变量40，所述输出变量对于相应的第二软件单元充当至少一个输入变量。

方法200可以包括：接收220用于相应的第一软件单元和相应的第二软件单元之间的接口的至少一个接口标准，其中所述接口标准包括针对第一软件单元的至少一个输出变量40的至少一个后置条件以及针对第二软件单元的至少一个输入变量50的至少一个先决条件，并且当所有先决条件都由相关联的后置条件满足时得到满足。

方法200还可以包括检查230是否满足用于所述接口的接口标准。

一般而言并且在方法200中，输出变量的后置条件必须限制为不超出输出变量的变量类型。换言之，输出变量对变量类型的值范围的计算规则可以是满射的。于是后置条件直接对应于输出变量位于输出变量的变量类型的值范围内的要求。同样，输入变量的先决条件必须被限制为不超出输入变量的变量类型。换言之，先决条件虽然不是必须的，但是仍然可以直接对应于输入变量位于输入变量的变量类型的取值范围内的要求。在这个意义上，方法200也可以应用于不需要先决条件和/或不需要后置条件的接口。

可以扩展方法200以考虑全局输入变量的后置条件和/或全局输出变量的输入变量，其中为每个全局输入变量或每个全局输出变量产生全局接口，在方法200中可以将该全局接口视为（常规）接口。

另一种计算机实现的方法200和/或替代的另一种计算机实现的方法200可以被设计为识别和/或避免软件系统10的软件单元20-25的集成中的集成错误。

方法200可以（如在方法100中那样）包括将软件系统10分解210为多个软件单元20-25。

在图4中示意性地示出了另一种计算机实现的方法200和/或替代的另一种计算机实现的方法200。

Claims (14)

1.一种用于对软件系统（10）进行静态检查的计算机实现的方法（100），所述软件系统分解为多个软件单元（20、21、22、23、24、25），

其中在所述软件单元（20-25）之间存在一个或多个接口，其中每个接口至少连接所述多个软件单元（20-25）中的相应的第一软件单元和相应的第二软件单元，使得相应的第一软件单元（20、21、22、23、24）具有对于相应的第二软件单元（20、21、22、23、25）充当至少一个输入变量（50）的至少一个输出变量（40）；

所述方法（100）包括：

接收（120）至少一个接口的上下文信息，其中所述上下文信息分别包括所述相应的第一软件单元的至少一个输出变量（40）的至少一个后置条件和/或所述相应的第二软件单元的至少一个输入变量（50）的至少一个先决条件；

接收（130）从所述多个软件单元（20-25）中对第三软件单元（20）的选择，使得产生（131）所述软件系统（10）向所述第三软件单元（20）和所述第三软件单元（20）的补集（30）的相关联替代分解，其中所述第三软件单元（20）和所述补集（30）形成所述软件系统（10）并且至少通过替代接口连接，使得所述补集（30）具有对于所述第三软件单元（20）充当输入变量（50）的至少一个输出变量（40）；

至少基于为所述至少一个接口接收（120）的上下文信息，为所述补集（30）的充当所述第三软件单元（20）的输入变量（50）的每个输出变量（40）选择（140）至少一个后置条件；

检查（150）一个或多个所选择（140）的后置条件是否能够在形式验证方面通过所述第三软件单元（20）前向传播（151）。

2.根据权利要求1所述的方法（100），其中，所述第三软件单元（20）和所述补集（30）至少也连接，使得所述第三软件单元（20）具有对于所述补集（30）充当输入变量（51）的至少一个输出变量（41）；

所述方法（100）包括：

至少基于至少一个上下文信息为所述补集（30）的通过所述第三软件单元（20）的输出变量（41）提供的每个输入变量（51）选择（141）至少一个先决条件；

检查（152）一个或多个所选择（140）的并且在形式验证方面通过所述软件单元前向传播（151）的后置条件是否满足为所述补集（30）的每个输入变量（51）选择（141）的一个或多个先决条件。

3.根据前述权利要求中任一项所述的方法（100），被设计为识别软件单元（20-25）和/或软件系统（10）中的运行时错误。

4.根据前述权利要求中任一项所述的方法（100），其中，一个或多个所产生（140）的后置条件通过所述第三软件单元（20）的前向传播（151）基于抽象计算。

5.根据前述权利要求中任一项所述的方法（100），包括：

如果关于一个或多个所选择（140）的后置条件是否能够在形式验证方面通过所述第三软件单元前向传播（151）的检查（150）是肯定的，则释放（160）所述第三软件单元（20）。

6.根据前述权利要求中任一项所述的方法（100），包括：

如果关于一个或多个所选择（140）的并且在形式验证方面通过所述软件单元前向传播（151）的后置条件是否满足为所述第三软件单元（20）的补集（30）的每个输入变量（51）选择（141）的一个或多个先决条件的检查（152）是肯定的，则释放（161）所述第三软件单元（20）。

7.根据前述权利要求中任一项所述的方法（100），其中，选择所述多个软件单元（20-25）中的至少一个另外的第三软件单元（21）并且类似于所述第三软件单元（20）来检查（150、152）和/或释放（160、161）所述至少一个另外的第三软件单元（21）。

8.根据前述权利要求中任一项所述的方法（100），包括：

将所述软件系统（10）分解（110）为多个软件单元（20-25）。

9.根据前述权利要求中任一项所述的方法（100），其中，接收（120）第一软件单元和第二软件单元之间的接口的上下文信息包括从注释、特别是从规范中

读取（121a）所述第一软件单元的至少一个输出变量（40）的至少一个后置条件，和/或

读取（121b）所述第二软件单元的至少一个输入变量（50）的至少一个先决条件。

10.根据前述权利要求中任一项所述的方法（100），其中，接收（120）第一软件单元和第二软件单元之间的接口的上下文信息包括

为所述第一软件单元的至少一个输出变量（40）产生（122a）至少一个后置条件，和/或

为所述第二软件单元的至少一个输入变量（50）产生（122b）至少一个先决条件。

11.根据权利要求10所述的方法（100），其中：

为所述第一软件单元的至少一个输出变量（40）产生（122a）至少一个后置条件基于所述第一软件单元的至少一个另外的输入变量的至少一个另外的先决条件，和/或

为所述第二软件单元的至少一个输入变量（50）产生（122b）至少一个先决条件基于至少一个另外的输出变量的至少一个另外的后置条件。

12.一种软件单元，其作为第三软件单元（20）按照根据前述权利要求中任一项的用于对软件系统（10）进行静态检查的计算机实现的方法（100）来检查（150、152）和/或释放（160、161）。

13.一种软件系统（10），在所述软件系统中多个软件单元（20-25）中的每个软件单元作为相应的第三软件单元（20）按照根据权利要求1-11中任一项的用于对软件系统（10）进行静态检查的计算机实现的方法（100）来检查（150、152）和/或释放（160、161）。

14.一种方法（300），包括：

-提供（310）根据权利要求13所述的软件系统（10）；

-可选地，使用（320）所述软件系统（10）。

Images