DE102022212057A1 - Method for analyzing functional paths for an embedded system, data processing device, computer program and computer-readable data carrier - Google Patents

Abstract

The invention relates to a method for analyzing functional paths (A-F; D-E) for an embedded system (10) which has at least one functional block (12) which has a software component (14) and an electronic component (16). It is provided that a hardware model description of the functional block (12) is generated in a hardware description language using a generated software component model of the software component (14) and a generated electronic component model of the electronic component (16). The hardware model description allows a comprehensive path analysis including a timing analysis of a functional block (12) comprising software and electronic components (14, 16).

Description

The invention relates to a method for analyzing functional paths, in particular functional safety paths, for an embedded system, a data processing device, a computer program and a computer-readable data carrier. The embedded system preferably comprises a control unit of a motor vehicle, preferably a self-driving motor vehicle.

Embedded systems typically consist of hardware and software that are embedded in a complex technical system, such as control units in motor vehicles. Such embedded systems can perform various control, regulation and data processing tasks in the technical system.

Control units in modern motor vehicles are growing disproportionately in complexity. In contrast to conventional vehicles, where the driver of the vehicle can react to a component failure to prevent something worse from happening, this is not possible with autonomous driving. In the area of autonomous vehicles in particular, increasing safety relevance and in-depth software structures are required to ensure safety in accordance with ASIL level (Automotive Safety Integrity Level) in the sense of functional safety development according to ISO 26262-2018.

ISO 26262 ("Road vehicles - Functional safety") is an ISO standard for safety-relevant electronic systems and their software in motor vehicles. Purely mechanical systems or problems that can be traced back to mechanical systems are not covered by ISO 26262. ISO 26262 defines a process model together with required activities and work products as well as methods to be used in development and production. In the development of a vehicle component, tens of thousands of requirements and architecture elements are therefore already defined that must be met.

The so-called "V-model" is usually used in development. The V-model is a linear process model in project management that divides a project into clearly defined phases. Test phases are added that are compared to the respective development phases. This means that not only system architecture or component specifications are created in development, but also the associated tests. This ensures that both the individual components and the overall system are tested and function as desired.

With today's technology, a large number of tests are carried out to check the safety of the product or component. However, a test is always only a static extract over time in the search space. In most cases, carrying out a complete test is impossible or simply not economical, as there is not an infinite amount of time and an infinite amount of testing capacity to carry out a complete test.

The document describes US 2019/0324422 A1 a solution aimed at preventing malfunctions of a control unit that can be traced back to "soft errors". Soft errors are errors that are caused by an error in the value of a data item or a signal generated by one or more components (or blocks) of the system, but are not the result of an error or defect in the underlying component or system, such as a defect, noise, electromagnetic interference, particle radiation or a transient error.

However, it has been shown that even with the greatest care, the occurrence of errors in the development and validation of products and components cannot be ruled out. In addition, the fact that a complete test is not possible creates an undesirable residual risk.

The invention is based on the object of developing a method which reduces the risk of errors in the development and validation of products and components.

The object according to the invention is achieved by a method for analyzing functional paths for an embedded system, a device for data processing, a computer program and a computer-readable data carrier according to the independent patent claims. Preferred developments are the subject of the respective dependent claims.

A first aspect relates to a method for analyzing functional paths, in particular functional safety paths, for an embedded system. The embedded system has at least one functional block, which comprises at least one software component and at least one electronic component. The embedded system preferably takes over control, regulation and/or data processing tasks of safety-relevant components and/or products.

In a process step, a software component model is created from the software component based on a combinatorial logic and a logical storage element. Based on further combinatorial logic and a further logical storage element, an electronic component model is generated from the electronic component. Furthermore, execution times are obtained from the software component and the electronic component. In a further step, a hardware model description of the functional block is generated in a hardware description language based on the software component model, the electronic component model and the obtained execution times. Using the generated hardware model description of the functional block, a path analysis, preferably a safety path analysis, is carried out.

The method according to the invention opens up the possibility of using path analysis to make a statement about the completeness and correctness of the paths present in the functional block, in particular the safety-relevant paths, compared to a given specification via the design of the product or component. The given specification is contained, for example, in the left-hand side of the V-model mentioned at the beginning and preferably includes the safety-relevant requirements and architectural elements of functional safety development mentioned in ISO 26262.

Because both the software and the electronic components are mapped in the hardware model description of the functional block and are available in a hardware description language, the entire software, including electronics, can be subjected to a complete path analysis using known tools and methodologies that are programmed for the environment of a hardware description language. This means that at least one functional path contained in the functional block can be output and checked. Preferably, a large number or all of the functional paths contained in the functional block are output and/or checked. This makes it possible to provide a mathematically complete counter-proof (according to the right-hand side of the V-model). This can sometimes eliminate the residual risk of the finite test series that occurs in the state of the art. The findings from the path analysis can be used to revise the left-hand side of the V-model (requirements and architecture elements) in order to increase and improve the safety of the product or component. The known model-based developments, such as tools from Mathworks Matlab/Simulink®, dSpace Toolkette® or Ansys SCADE®, do not offer these options. The known solutions focus only on the modeling of functional content and do not go beyond the complexity class with regard to the analysis of a single dedicated software component. In other words, the method according to the invention enables a more in-depth analysis of functional safety paths in the products and components in order to indicate completeness. This increases familiarity (confidence based on ISO 26262). The method is also able to analyze several safety-relevant triggers and reactions and to uncover multiple errors. This makes it possible to check error concealment or error priorities.

A functional block preferably represents a capsule for data and algorithms that can provide one or more functionalities of the embedded system. The algorithms convert the input signals into output signals depending on the internal data. The electronic component preferably comprises an electronic system for preprocessing the input signals and an electronic system for controlling and outputting the output signals, for example a control signal for an actuator. The software component preferably comprises one or more algorithms for converting the input signals into the output signals. The software component preferably has one or more commands or a sequence of commands, where a command can be a single instruction of a program, such as a memory access, a calculation (addition, multiplication, etc.), an assignment, a comparison between two values or the like that can be carried out by an embedded system.

The embedded system is not limited to one function block. Preferably, the embedded system comprises a plurality of function blocks. These are also preferably assembled into a so-called composite function block in order to implement more complex requirements. Preferably, a hardware model description is generated analogously in a hardware description language for each function block. Furthermore, the function block or the plurality of function blocks can also have a plurality of software components and/or electronic components in order to implement more complex requirements. The software component and/or the electronic component can have one or more input values and one or more output values. Preferably, a corresponding software and/or electronic component model is generated for each software and/or electronic component and used to generate the hardware model description.

The software component model and/or electronic component model preferably represent a mapping or modeling of the software component and/or the electronic component in a hardware description language. The mapping or modeling of the software component represents the logic of the sequence of commands of the software component based on a combinatorial logic and a logical storage element. The mapping or modeling of the electronic component represents the processes of preprocessing the input signals (for example filtering) and processing and outputting the output signals (for example control signals) of the electronic component based on another combinatorial logic and another logical storage element. The software component model and the electronic component model can in principle be read and edited by a computer.

A combinatorial logic is preferably a set of logical operations (AND, OR, NOT, NAND, NOR, XOR, etc.) between input values obtained at an input component of the combinatorial logic and output values provided at an output component. The input values correspond, for example, to the values passed to the software component when it is executed on the embedded system, and the output values correspond to the values calculated by the software component.

A logical storage element is preferably a latch, a flip-flop or the like. This makes it possible to model the storage of the output values in order to reflect a transfer of values or a data exchange between the electronic and/or software components.

In a preferred embodiment, the path analysis is carried out using a tool for timing and path analysis. Examples of such tools are Synopsys Primetime® or Design Compiler®. The path analysis can be carried out easily by using already known tools. Such tools are designed, for example, to analyze paths and runtimes, for example to carry out content-related structural analyses in order to enable a comparison with a specification.

In a further preferred embodiment, when carrying out the path analysis, a content structure analysis and a predefined specification are used to check whether a functional path contained in the existing functional block meets one of the predefined specifications. Preferably, a check is carried out to see whether a large number or all of the functional paths contained in the existing functional block meet all of the predefined specifications. If a predefined specification (for example according to ISO 26262) is not met, i.e. if the functional block does not contain a functional path corresponding to the predefined specification, there is a design gap or an error in the product or component. In this case, an error message is preferably issued, in particular with the message that the predefined functional path does not exist. This serves to check whether the intended safety requirements, as required by ISO 26262, for example, are met or not.

In a further preferred embodiment, when carrying out the path analysis, a content structure analysis and a given specification are used to check whether the function block includes a number of functional paths per given specification of two or more. If a corresponding number of two or more is found, an error message is preferably issued, in particular with the message that a number of functional paths per given specification of two or more exists. Usually, when developing products or components, one functional path is constructed per given specification. If there is more than one functional path per given specification in the function block, there are functional paths that do not correspond to the specification. This is a so-called overengineering example. Overengineering represents a significant cost driver in development and also unnecessarily increases the complexity of a product or component. Furthermore, the risk of security gaps (functional security as well as cyber security) is increased.

In a further preferred embodiment, when carrying out the path analysis, a content-related structural analysis and a given specification are used to check whether all of the functional paths provided for in the given specification are present in the function block. As already explained, this serves to check whether the intended safety requirements, as required by ISO 26262, for example, are met or not.

In a further preferred embodiment, when carrying out the path analysis, a timing analysis is used to check whether one of the execution times exceeds or falls short of a given specification time. If the specification time is exceeded, before an error message is preferably issued, in particular with the message that the relevant execution time has been exceeded. If the specification time is not met, an OK message is preferably issued, in particular with the message that the relevant execution time has not been exceeded. This can be used to check whether reactions occur within specified times. If this is not the case, this can lead to a safety-relevant malfunction or to the system reacting too late. In this respect, timing analysis is used to check whether the specified safety requirements, as required by ISO 26262, for example, are met or not. The execution time of a software and/or electronic component is preferably a period of time that the software and/or electronic component on an embedded system needs to process all commands and provide an output value.

In a further preferred embodiment, sensor values and/or bus information are used as input and/or output values of the function block. Examples of bus systems are Can, CanFD, Flexray, Lin or Ethernet. Consequently, the method can be applied to a large number of different embedded systems. Furthermore, the embedded system comprises one or a large number of actuators which can be controlled by the output signal of the function block.

The above-mentioned embedded system, for example a control unit for a motor vehicle, is preferably implemented by electrical or electronic parts or components (hardware) or by firmware (ASIC). The embedded system can have an FPGA (Field Programmable Gate Array), a DSP (digital signal processor) or the like. Additionally or alternatively, the functionality of the control unit is implemented when executing a suitable program (software). The embedded system is also preferably implemented by a combination of hardware, firmware and/or software. For example, individual components of the embedded system are designed as a separate integrated circuit to provide individual functionalities or are arranged on a common integrated circuit.

The individual components of the embedded system are also preferably designed as one or more processes that run on one or more processors in one or more electronic computing devices and are generated when executing one or more computer programs. The computing devices are preferably designed to work together with other components, for example a communications system, in order to implement the functionalities described herein. The instructions of the computer programs are preferably stored in a memory, such as a RAM element. However, the computer programs can also be stored in a non-volatile storage medium, such as a CD-ROM, a flash memory or the like.

It will also be apparent to those skilled in the art that the functionalities of multiple computing units (data processing devices) may be combined or combined in a single device, or that the functionality of a particular data processing device may be distributed across a plurality of devices to implement the functionality of the embedded system.

A further aspect relates to a device for data processing, comprising means for carrying out the steps of the method according to the invention, in particular a method for analyzing functional paths for an embedded system. The device for data processing is preferably a computer, a server, a computer network, for example a computer cluster or a cloud, or the like. The means is preferably a processor, a memory element, an electronic circuit or an electronic component that is typically used to carry out the function described herein.

A further aspect relates to a computer program comprising instructions which, when the program is executed by a computer, such as an embedded system, for example a control unit for a motor vehicle, cause the computer to carry out the method according to the invention, in particular a method for analyzing functional paths for an embedded system. The program is preferably executed on a computer, a server, a computer network and/or in a cloud. The above-mentioned computer can therefore generally be understood as a device for data processing. In some embodiments, in particular in which the computer program is executed on a computer network, steps of the method described herein are preferably executed in parallel. A higher complexity analysis is then achieved through parallel calculations.

A further aspect relates to a computer-readable data carrier on which the computer program according to the invention is stored. A computer-readable data carrier is preferably a semiconductor memory, a magnetic hard disk, a optical storage (like a DVD etc.) or the like.

Further preferred embodiments of the invention emerge from the remaining features mentioned in the subclaims.

The various embodiments of the invention mentioned in this application can be advantageously combined with one another, unless stated otherwise in individual cases.

• 1 eine schematische Darstellung eines eingebetteten Systems;
• 2 eine schematische Darstellung des Verfahrens gemäß einer Durchführungsform und
• 3 eine schematische Darstellung einer Vorrichtung gemäß einer Ausführungsform.

The invention is explained below in exemplary embodiments with reference to the accompanying drawings. They show:

• 1 a schematic representation of an embedded system;
• 2 a schematic representation of the method according to one embodiment and
• 3 a schematic representation of a device according to an embodiment.

1 shows a schematic representation of an embedded system 10. In this embodiment, the embedded system 10 is a control unit for a motor vehicle. The embedded system 10 takes over control, regulation and data processing tasks in the motor vehicle. However, the invention is not limited to this. Rather, the invention can also be transported to other industries, such as shipbuilding, aviation, aerospace, medicine, nuclear industry and the like.

The embedded system 10 comprises a functional block 12, which in turn has three software components 14 and two electronic components 16. The functional block 12 receives sensor values from a sensor 18 of the motor vehicle as an input signal. The sensor values are preprocessed, for example filtered, in the first electronic component 16. Using the software components 14, the sensor values are evaluated, for example converted, and a corresponding control signal generated by the second electronic component 16 is output to an actuator 20 as an output signal of the functional block 12. The second electronic component 16 is power electronics for controlling the actuator 20. The actuator 20 is, for example, an electric motor that actuates a brake of the motor vehicle, a steering of the motor vehicle or the like according to the output signal of the functional block 12.

As in 1 shown, the paths A to F shown as examples result in the function block 12. The method according to the invention should be explained as clearly as possible using the small number of paths A to F selected, without being limited to this. The arrow (not shown in more detail) from the sensor 18 to the function block 12, more precisely to the first electronic component 16, illustrates a transmission of the sensor values recorded by the sensor 18 as an input signal for the function block 12. From the first electronic component 16 onwards, only two functional paths AF and DF are shown for the sake of clarity. However, it is obvious that modern control units can comprise tens of thousands of functional paths, a large number of sensors 18 and bus systems that supply the function block with input signals, and a large number of actuators for controlling a wide variety of functions of the motor vehicle, which are controlled by output signals from the function block 12.

The first functional path A-F leads via a first and second software component 14 to the second electronic component 16 and from there to the actuator 20. The path A-F corresponds, for example, to a regular control of the actuator 20 by the control unit depending on the sensor values recorded by the sensor 18. The first software component 14 receives the preprocessed sensor values from the first electronic component 16 (path A). The received sensor values are then evaluated by the first software component 14 and the result of the evaluation is passed on to the second software component 14 (path B). The second software component 14 determines a reaction to be initiated based on the result of the evaluation and passes the information about the desired reaction to the second electronic component 16 (path C). The second electronic component 16 creates and transmits a control signal, which regulates the actuator 20 in such a way that the desired reaction is implemented, to the actuator 20 (path F).

The second functional path D-F leads via a third software component 14 to the second electronic component 16 and from there to the actuator 20. The path D-F corresponds, for example, to a functional safety path which is intended to prevent the actuator 20 from being activated at any given time in the event of predetermined situations which can be identified, for example, from the sensor values of the sensor 18. The third software component 14 receives the preprocessed sensor values from the first electronic component 16 (path D) and determines whether a current sensor value gradient exceeds a threshold value. If this is the case, the third software component 14 transmits a signal to deactivate the second electronic component 16 (path E). This signal then prevents the actuator 20 from being activated via path F.

2 shows a schematic representation of a method according to an embodiment. The method is for the analysis of functional paths, for example the functional safety paths AF; DE as in 1 shown, suitable for an embedded system 10. The embedded system 10 is preferably the one in 1 described control unit for a motor vehicle.

According to a first method step 50, a software component model is generated from the software components 14 based on a combinatorial logic and a logical storage element.

In a second method step 52, an electronic component model of the electronic components 16 is generated based on a further combinatorial logic and a further logical storage element.

According to a third method step 54, execution times are obtained from the software components 14 and the electronic components 16.

In a fourth method step 56, a hardware model description of the functional block 12 is generated in a hardware description language based on the software component models, the electronic component models and the obtained execution times.

Consequently, a path analysis is performed using the generated hardware model description of the functional block 12 (method step 58).

Since the hardware model description of the function block 12 is available in a hardware description language, a path analysis can be carried out on the entire software including the electronics using known tools for timing and path analyses, such as Synopsys Primetime® or Design Compiler®. The path analysis is used, for example, to check whether there is a safety-relevant path from the first electronic component 16 to the actuator 20 that sets the path F to zero, i.e. no actuator activity, which corresponds, for example, to a safety state in the event of an error. The tool for timing and path analyses would be 1 the two functional safety paths AF and DF are output. Using a content structure analysis, the tool can also indicate whether both paths AF and DF can actually set path F to zero. By comparing with a given specification, for example ISO standard 26262, it can now be checked whether the two paths AF and DF correspond to the specification. If, for example, the specification states that there should only be one path that can set path F to zero, and it is determined using the tool that both paths AF and DF are equipped with this function, a functional path would be found that would not be according to the specification. This would be an example of overengineering.

Furthermore, the path analysis can also be used to determine whether the function block 12 contains all the functional safety paths that should be included according to the specification. If the specification states that in the 1 If a path AE is also required in the example shown, the tool would not find this path and would report that the path does not exist. Consequently, a design gap or a defect in the product or component would be found.

Since the hardware model description also contains the execution times of the software and electronic components 14, 16, the tool can also be used to check whether the reaction of the actuator 20 occurs within a predetermined specification time after receipt of the sensor values. For example, a reaction time of 20 ms could be specified by the specification if a current sensor value gradient exceeds the threshold value described above. The tool can therefore also be used to verify whether the specification times required in the specification are adhered to.

3 shows a schematic representation of a data processing device 100 according to an embodiment. The device 100 is a computer. A computer program 102 is stored on a computer-readable data carrier 104. The computer program 102 contains instructions which, when the computer program 102 is executed by the data processing device 100, cause it to carry out the method described herein.

List of reference symbols

10

embedded system

12

Function block

14

Software component

16

Electronic component

18

sensor

20

Actuator

50

first procedural step

52

second process step

54

third procedural step

56

fourth procedural step

58

fifth procedural step

100

Device for data processing

102

computer program

104

computer-readable data carrier

A - F

Paths

QUOTES INCLUDED IN THE DESCRIPTION

This list of documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions.

Cited patent literature

• US 20190324422 A1 [0007]

Claims (10)

Method for analyzing functional paths (A-F; D-E), in particular functional safety paths, for an embedded system (10) which has at least one functional block (12) which has at least one software component (14) and at least one electronic component (16), which comprises the method steps: Generating (50) a software component model of the software component (14) based on a combinatorial logic and a logical storage element, generating (52) an electronic component model of the electronic component (16) based on another combinatorial logic and another logical storage element, Obtaining (54) execution times from the software component (14) and the electronic component (16), Generating (56) a hardware model description of the functional block (12) in a hardware description language based on the software component model, the electronic component model and the obtained execution times, and Performing (58) a path analysis using the generated hardware model description of the functional block (12). Procedure according to Claim 1 , where the path analysis is performed using a timing and path analysis tool. Procedure according to Claim 1 or 2 , wherein when carrying out the path analysis, it is checked by means of a content structure analysis and a predetermined specification whether a functional path (AF; DE) contained in the existing functional block (12) fulfills one of the predetermined specifications. Method according to one of the preceding claims, wherein when carrying out the path analysis, it is checked by means of a content structure analysis and a predetermined specification whether the functional block (12) comprises a number of functional paths (A-F; D-E) per predetermined specification of two or more. Method according to one of the preceding claims, wherein when carrying out the path analysis, it is checked by means of a content structure analysis and a predetermined specification whether all of the functional paths provided in the predetermined specification are present in the functional block (12). Method according to one of the preceding claims, wherein when carrying out the path analysis, a timing analysis is used to check whether one of the execution times exceeds or falls short of a predetermined specification time. Method according to one of the preceding claims, wherein sensor values and/or bus information are used as input and/or output values of the function block (12). Data processing device (100) comprising means for carrying out the steps of the method according to one of the preceding claims. Computer program (102) comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method according to one of the Claims 1 until 7 to execute. Computer-readable data carrier (104) on which the computer program (102) according to Claim 9 is stored.

Images