Computer-Assisted Design Method for Mechatronic Systems

Abstract

A method for computer-assisted system design includes: providing a textual system description that defines a desired behavior of a vehicle; converting, using a computer, the textual system description into a linear temporal logic (LTL) formula; converting, using the computer, the LTL formula into a first automaton; providing, using the computer, a second automaton representing system dynamics of the vehicle; and generating, using the computer, a testing automaton by combining the first and the second automaton.

Claims

1. A method for computer-assisted system design, the method comprising: providing a textual system description that defines a desired behavior of a vehicle; converting, using a computer, the textual system description into a linear temporal logic (LTL) formula; converting, using the computer, the LTL formula into a first automaton; providing, using the computer, a second automaton representing system dynamics of the vehicle; and generating, using the computer, a testing automaton by combining the first and the second automaton.

2. The method of claim 1, further comprising: generating a hardware description language (HDL) model of the testing automaton; and implementing, using the computer, the testing automation in hardware.

3. The method of claim 1, wherein converting the textual system description into the LTL formula comprises: decomposing the textual system description into keywords, which represent logic operators and modal temporal operators of a linear temporal logic (LTL), and text passages linked by the keywords; generating, using the computer, software function definitions corresponding to the text passages linked by the keywords; and generating the LTL formula based on the software function definitions and the operators defined by the keywords.

4. The method of claim 1, wherein providing the second automaton representing the system dynamics comprises: providing a model representing the system dynamics of the vehicle; discretizing the model to obtain a discrete model; and converting the discrete model into an automaton.

5. The method of claim 1, wherein the textual system description is automatically enhanced to include redundancy.

6. The method of claim 1, wherein the textual system description includes a set of traffic rules.

7. A controller module for controlling a vehicle, the controller module comprising: a controller configured to execute a controller task to control the vehicle; a programmable logic configured to execute a testing automaton designed by converting a textual system description that defines a desired behavior of the vehicle into a linear temporal logic (LTL) formula, converting the LTL formula into a first automaton, providing a second automaton representing system dynamics of the vehicle, and generating the testing automaton by combining the first and the second automaton; and at least one sensor configured to obtain sensor information, wherein the controller is configured to provide one or more set-points representing the movement of the vehicle to the programmable logic, wherein the programmable logic is configured to check, based on the sensor information, whether the one or more set-points are compliant with desired behavior of the vehicle defined by the textual system description.

8. The controller module of claim 7, wherein the textual system description includes a set of traffic rules.

9. A non-transitory computer readable medium storing a computer program operable for computer-assisted system design, the computer program comprising: program instructions to convert a textual system description that defines a behavior of vehicle into a linear temporal logic (LTL) formula; program instructions to convert the LTL formula into a first automaton; program instructions to provide a second automaton representing system dynamics of the vehicle; and program instructions to generate a testing automaton by combining the first and the second automaton.

10. The non-transitory computer readable medium of claim 9, wherein the computer program further comprises: program instructions to generate a hardware description language (HDL) model of the testing automaton; and program instructions to implement the testing automation in hardware.

11. The non-transitory computer readable medium of claim 9, wherein the program instructions to convert the LTL formula into the first automaton comprise: program instructions to decompose the textual system description into keywords, which represent logic operators and modal temporal operators of a linear temporal logic (LTL), and text passages linked by the keywords; program instructions to generate software function definitions corresponding to the text passages linked by the keywords; and program instructions to generate the LTL formula based on the software function definitions and the operators defined by the keywords.

12. The non-transitory computer readable medium of claim 9, wherein the program instructions to provide the second automaton representing the system dynamics of the vehicle comprise: program instructions to provide a model representing the system dynamics; program instructions to discretize the model to obtain a discrete model; and program instructions to convert the discrete model into an automaton.

13. The non-transitory computer readable medium of claim 9, wherein the textual system description includes a set of traffic rules.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The invention can be better understood with reference to the following description and drawings. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. Moreover, in the figures, like reference numerals designate corresponding parts.

[0012] In the drawings:

[0013] FIG. 1 shows the V-model for mechatronic applications;

[0014] FIG. 2 shows the simplified workflow according the V-model by John Russell of BAE during his presentation at the Matlab EXPO 2015;

[0015] FIG. 3 shows the automation of the lower part of the V-model by using tools as offered by Mathworks® here shown as green boxes;

[0016] FIG. 4 shows the degree of automation achievable by the method presented herein;

[0017] FIG. 5 is a visualization of an exemplary system specification;

[0018] FIG. 6 shows the different function heads generated from the function non-translatable text;

[0019] FIG. 7 shows the result the procedure to convert both formulas into automata;

[0020] FIG. 8 shows the result of a linearization of a non-linear system;

[0021] FIG. 9 shows the result of an environment-driven discretization;

[0022] FIG. 10 is an example of a transition system as shown in Wikipedia;

[0023] FIG. 11 illustrates an exemplary transition matrix for the transition system of FIG. 10;

[0024] FIG. 12 illustrates different way to represent an environmental based discretization;

[0025] FIG. 13 shows the automata for a controller based discretization of the above dynamics;

[0026] FIG. 14 shows an exemplary situation to be tested;

[0027] FIG. 15 shows the results of the verification for different waypoints WP1 . . . WPn;

[0028] FIG. 16 shows the integration of a camera, OBD device with a function;

[0029] FIG. 17 shows a potential integration test for a camera which should detect a traffic light; and

[0030] FIG. 18 summarizes the automation of the development process of an exemplary mechatronic system (such as an autonomous car).

DETAILED DESCRIPTION

[0031] With the method and systems described below a (semi-)automation of the process, which has been described in the Background section, may be achieved to further decrease the cost of the V-model development cycle. FIG. 4 illustrates the degree of automation achievable with the method described herein.

(a) Language Conversion and Specification

[0032] A text is given as a specification to define the behavior of a vehicle. For example (see FIG. 5): [0033] vehicle start in (1), [0034] vehicle always stay in environment [0035] vehicle always avoid obstacle (3) to the right [0036] vehicle go to (4)
Additionally, the specification may include traffic rules like provided, for example, in the applicable laws and regulations. [0037] If there is a traffic light apply traffic light rules, [0038] If the traffic light is red, vehicle must stop, [0039] If the traffic light is orange, vehicle may stop, [0040] If the traffic light is green, vehicle can drive, [0041] If the traffic light blinks orange, vehicle might,
The text can be given as paragraphs and sub-paragraphs.

[0042] In the next step the effect onto a potential system failure is analyzed for each line of the above text. ISO 61508 and other similar standards use the so called Failure Mode and Effects Analysis (FMEA) or similar techniques to estimate the criticality level of a text line. Depending on the standard used, this can be done using the risk priority number (RPN). The procedure on how to obtain the RPN depends on the used standard and will not be discussed here as it can be found in the according standards.

[0043] The results of the FMEA analysis are tests and its testing requirements and/or the criticality level and/or other elements which must be considered during the design process of the function. Tests and its testing requirement defines e. g. the necessary detection rate or precision of a function (including sensor) to be tested, so that the function can be considered safe enough to be used on the system. This is especially important for integration tests (will be explained later). The criticality level can lead to design recommendations of the function e. g. the function must be redundant and system structure of the design must provide corresponding redundancy.

[0044] After applying the mentioned procedures each sentence will have some information about the necessary tests and its testing requirements and the recommended system structure which can be stored like

red traffic light vehicle must stop; redundant; 1e-3 detection rate; . . . ; . . . ;
To use both texts as requirements specification they are used as written but modified by words which are used to define linear temporal logic (LTL) or its extensions. Such words are [0045] Not [0046] Or [0047] And [0048] Always [0049] Eventually [0050] Next [0051] . . .
Applying these words in the above example may result in

TABLE-US-00001   vehicle always stay in environment and avoid obstacle (3) to the right and do not drive faster then 50 km/h and apply traffic light rules  red traffic light vehicle must stop  or  yellow traffic light vehicle should stop  or  green traffic light vehicle must drive  or  not working traffic light apply normal traffic rules
In the case that an information of one sentence requires redundancy or a special system design in the next step, a program uses this information in order to add these requirements to the text. This additional requirements must follow the standards if available (e. g. IEC 61508). As a simple example it is referred to the above example to make the “red light”-sentence redundant. The result of the processing could look like:

TABLE-US-00002 vehicle always   stay in environment and avoid obstacle (3) to the right and do not drive faster then 50 km/h and apply traffic light rules  red traffic light vehicle must stop   red traffic light vehicle must stop_1   or   red traffic light vehicle must stop_2  or  yellow traffic light vehicle should stop  or  green traffic light vehicle must drive  or  not working traffic light apply normal traffic rules

[0052] Subsequently, a program is applied which converts all lines, which are not keywords into function definitions (see FIG. 6). The function definitions can be generated for any programming language like C/C++ or for high level programming languages like Matlab/Simulink. In the next step, the translatable text is converted into an LTL formula using pattern matching and it is combined with the results of the functions. Referring to FIG. 6, a sub-paragraph is written in

LTL=res1res2res3res4

and the second one is

res3=(res3_1res3_2res3_3res3_4)

If a keyword is found it is replaced by a corresponding functional operator (NOT (¬), OR (), AND (), ALWAYS (G), Eventually (F), NEXT (X), etc.). The resulting LTL formula is then converted into a (Büchi) automaton (e.g. Büchi Automaton, which is a type of ω-automaton, which extends a finite automaton to infinite inputs) or similar state machine using a method as proposed, for example, in one of the following internet publications: [0053] en.wikipedia.org/wiki/Linear_temporal_logic_to_B%3%BCchi_automaton or [0054] www.lsv.ens-cachan.fr/˜gastin/lt2ba/

[0055] For a better understanding of the procedure it is graphically illustrated in FIG. 7. It is also possible that some keywords are included in the not translatable lines. This may be considered in future applications.

(b) Mathematical Model

[0056] On the other side the mathematical model of the non-linear dynamics is given.

{dot over (x)}=f(x,u)

The dynamic model is discretized which also results in an automaton (state machine). The discretization can be done in different ways. The most common and best known way is to discretize the system is linearization of the generally non-linear dynamics using the Jacobi Matrix. The result of the linearization is a timed automaton where the discrete states of the automaton are discrete time stamps and the jump functions is the sample time. FIG. 8 shows the results of this discretization.

[0057] Another approach is the environment-driven discretization where a working area is divided into different sub-areas as shown in FIG. 9. The individual sub-areas can be marked as occupied or not occupied. In FIG. 9 an area is represented a polytope where one discrete state q.sub.i is represented as the center of a polytope. Pages 11ff. of the publication M. Althoff, Reachability Analysis and its Application to the Safety Assessment of Autonomous Cars, PHD-thesis, TU München, 2010, shows different ways to represent polytopes based on line half-space (H-) representation or based on vertex (V-) space representation. There are other ways to represent polytopes (see FIG. 10).

[0058] Within one discrete (sub-) area the conditions (such as unoccupied, occupied, etc.) are the same. The discrete automaton can then be seen as a transition system from one discrete point to another and be represented as a transition matrix. FIG. 10 represent the transition system for 3 discrete state q.sub.1=1, q.sub.2=2 and q.sub.3=3. The jump functions (i.e. transition functions) are the distances between the discrete states according to a predefined metric (they could be also 0 for no connection between two discrete state and 1 for a connection, however, also a value between 0 and 1, which represents a probability, could be possible). FIG. 11 shows the transition matrix of the transition system in FIG. 10.

There might be other ways to discretize the operating environment (working area). For example, an environmental driven discretization of the non-linear dynamics could be represented as circles (encompassing occupied parts of the environment) with a predefined radius. FIG. 12 shows the discrete environment as

q.sub.1\(q.sub.2∩.sub.q3∩q.sub.4).

A controller-based or behavior-based discretization can be using the following procedure. Here a differential equation as it is commonly used in order to describe the dynamics of vehicles like aircrafts or cars is used. In the literature this is also known as “Dubins car”.

{dot over (x)}=v.Math.cos(ψ)

{dot over (y)}=v.Math.sin(ψ)

{dot over (ψ)}=ω

ω=[ω.sub.min,0,ω.sub.max]

v=[v.sub.min,0,v.sub.max]

u=[v,ω]

For the following cases the discrete automata can be defined as (see FIG. 13) [0059] ω=ω.sub.min<0 . . . q.sub.1=left [0060] ω=0 . . . q.sub.2=straight [0061] ω=ω.sub.max>0 . . . q′=right

[0062] The discrete transition function can be defined according a metric or a based on physical, graphical or stochastically functions. It is also possible to use discretize v and ω in predefined discretization steps n.sub.dist so that

[00001]$\omega =\left[{\omega }_{min},{\omega }_{min}+i.Math.\frac{{\omega }_{max}-{\omega }_{min}}{n_{\mathrm{dist}}},.Math.,{\omega }_{max}\right],i\in \left[1.Math.i_{max}\right].$

(c) Automatic Test Generation

[0063] Applying the cross product to the two automata (state machines) gives a new state machines which is the automatically generated test as seen in FIG. 4 which is also called verification. If the result of the automata is positive the verification is positive which means that the automata of the model satisfies the specifications. The mathematical background for the cross product can be found on p. 11 of the publication Bruno Filipe Araujo Lacerda, “Linear-Time Temporal Logic Control of Discrete Event Systems”, Master Thesis, Universidade Téchnica de Lisboa, September 2007.

[0064] Instead of using all discrete states of the state machine of the model it is also possible to use only one state in order to do the verification.

(d) Code Generation for Automatically Generated Test and Deployment on Target Hardware

[0065] A program then uses the resulting state machine in order to automatically generate it into C/C++ code or in Verilog/VHDL code or any other programming language. Verilog/VHDL is used in order to accelerate the verification process. Using standard development programs for FPGAs the source code then deployed onto the FGPA.

(e) Implementation of the Function

[0066] After the function interface is generated the function must be implemented such that the behavior of the function fulfills the written sentence. This is typically done in a simulation environment like Matlab. As example consider the following sentence: [0067] avoid obstacle (3) to the right
which means that the autonomous system must avoid the obstacle to the right (which is one of the main behaviors required by the rules of the air in order to integrate UAVs into the civil airspace). As shown in FIG. 14 the question which must be answered is which of the way points WP1, . . . , WPn satisfies the written specification. So the function must contain a test which generates a positive result to the collision avoidance of the car to right. In order to do that the function needs to have the information about the distance to the obstacle, the velocity and the heading of the car, the cars dynamic behavior (turning radius in relation to velocity) and the information if a waypoint WPi is reachable.

[0068] The reachability of a potential waypoint WPi can be calculated in different ways. One way to do it is to use symbolic available results for Dubins car as presented by on pp 28, in the publication Matthias Althoff, Reachability Analysis and its Application to the Safety Assessment of Autonomous Cars, PHD-thesis, TU München, 2010, and publication Marius Kloetzer, Symbolic Motion Planning and Control, PHD-thesis, Boston University, 2008.

[0069] Assuming now that there is a method implemented which solves the reachability problem for a given dynamics a test in the function has to calculate the results as shown in FIG. 15. The red dots show potential waypoints which do not satisfy the specification that the car should avoid the obstacle to the right and the green dots (marked with arrows) show that they satisfy the specifications.

[0070] The generated function will use the input of a sensor which is able to detect the obstacle and the velocity, heading and the steering angle of the car. The function returns as a return value [0071] 0 (red dots) if the waypoint does not satisfy the specification [0072] 1 (green dots) if the waypoint does satisfy the specification
Additionally, the function can return the minimum and maximum values for the set points of the velocity and steering angle controller of the car.

(f) Code Generation of the Function and Testing

[0073] In the next step the high level code function developed in the last step is automatically generated into a source code which can be used on the target board. Additionally, module tests are automatically generated so that the automatic generated source code can be tested against the high level function. Such test may include: [0074] Function test, [0075] Black box test, [0076] Probabilistic test, [0077] Interface test, [0078] Performance test, [0079] Software-in-the-loop tests.
These tests are then applied to the code generated functions and compared to the high level code functions.

(g) Integration Tests

[0080] As described above for each functions requirements are defined either by the customer or FMEA analysis. In order to prove that a subsystem satisfies the requirements integration tests have to be developed. FIG. 16 illustrates the integration of a camera as an OBD device associated with a function (e.g. traffic_light_is_orange(sensor, vehicle_cond)).

[0081] FIG. 17 shows a potential setup of an integration test for a camera which should detect the orange color of a traffic light. The traffic light is displayed on a screen in different sizes in order to simulate the distance to the camera. To simulate the environmental conditions a stochastic model is used in order to produce noise which is added to the simulated traffic light. The camera is mounted in the test rig and look onto the screen. The images are forwarded to the “traffic_light_is_orange” function and the result of the function is forwarded. The testing computer counts the number of detection. The test is repeated until the necessary number of tests is reached. The achieved detection rate is compared to the specified detection rate. In the case that the detection rate is below the specified detection rate the subsystem is mounted onto the autonomous system is ready to be used. In the case it is not fulfilled, adjustments to the subsystem have to be made and the V-model is repeated.

(h) Adjustment

[0082] In the case that during operation a situation arises which is not covered by the existing specification a special case specification is added to the existing specification. The whole development procedure according the V-model is repeated so that the special case can be handled by the autonomous system.

(i) Deploying to the System

[0083] The automatically generated VHDL/Verilog code and the tested sub-system are implemented on the autonomous system. Each subsystem delivers a result to the state machine for verification.

(j) Scientific Background

[0084] Claire Tomlin et al. (Tomlin, Claire, Ian Mitchell, Alexandre. M. Bayen, Meeko Oishi, 2003, Computational Techniques for the Verification of Hybrid Systems, Proceedings of the IEEE, pp. 986-1001) outlined the reachability analysis based on state space exploration as the major tool to verify Hybrid systems. Hybrid systems are systems which combine discrete and continuous dynamics to one model. Methods to solve the reachability problem can be divided into over-approximation methods and convergent approximation methods.

[0085] Over-approximating methods try to efficiently over-approximate the reachable set while the state representation typically scales polynomial with the continuous state space dimension n, with some exceptions. Since the execution time and memory requirement generally scales linearly with the size of the reachable state representation such methods have a significant advantage over other methods. On the other side the come with the disadvantage that the methods are to imprecise to cover non-linear dynamics and for which the shape of the reachable set is not a polygon or an ellipse.

[0086] Convergent approximating methods try to represent the reachable set as closely as possible while the state representation scales exponentially with n. This result to the fact that these methods are not practical for dimensions larger than five, but come with the advantage that non-linear dynamics can be covered and they make no assumptions on the shape of the reachable set.

[0087] Matthias Althoff (Matthias Althoff, Reachability Analysis and its Application to the Safety Assessment of Autonomous Cars, phd-thesis, TU München, 2010) uses idea of over-approximation in and applies it to non-linear systems by linearizing them around a working point and integrating them. He uses polygons to describe the reachable sets of the system after each integration step. He extends the idea to so-called stochastic state safety verification where he proposes to abstract a Markov-Chain out of the original hybrid dynamics. This is done by discretization of the continuous dynamics, resulting in state space regions which are defined as the discrete states of the Markov-Chain. The advantage of this method is that it is possible to derive control strategies which can minimize the risk of a collision while the disadvantage of this method is the exponential growth of the discrete states with the number of continuous states. Over the last couple of years he applied this techniques to different applications like safety verification of autonomous cars or automatic landing of helicopters.

[0088] So far the outlined methods are used to solve the typical robot navigation problem “Go from A to B and avoid collisions”. Such specifications can be formulated as inequalities, e. g. as circles around the point which should be reached or which should be avoided. More expressive specifications like “Always avoid a collision to the right” (as stated in the rules of the air) might be of interest.

[0089] Marius Kloetzer and Calin Balta (see Marius Kloetzer, Symbolic Motion Planning and Control, phd-thesis, Boston University, 2008, ISBN 054954729, and Marius Kloetzer, Calin Belta, A fully automated framework for control of linear systems from temporal logic specifications, IEEE Transaction on Automatic Control, 2008) proposed two methods that focus on more expressive specifications and which are not based on state space exploration but on the environment-driven discretization also called top-down approach and a controller-driven discretization also called bottom-up approach. The approach proposed in these works are between the both mentioned methods. Besides the advantage to use more expressive specifications in form of linear temporal logic (LTL) another advantage is the reduction of the number of discrete state spaces which gives a clear advantage in terms of time and memory requirement.

[0090] Luis Reyes Castro et al. (Luis I. Reyes Castro, Pratik Chaudhari, Jana Tumovay. Sertac Karaman, Emilio Frazzoli, Daniela Rus, Incremental Sampling-based Algorithm for Minimum-violation Motion Planning, Decision and Control (CDC), 2013 IEEE 52nd Annual Conference on, 3217-3224) showed probably the first time an implementation of a verified control algorithm which is able to handle safety rules (rules of the road) while fulfilling a given reachability task. The proposed solution is based on a Rapidly-exploring Random Trees (RRTs) algorithm which incrementally designs a feasible trajectory for a real time application. Since the proposed approach is iterative, as understood, so still running while already executing the action, the results can lead to very dangerous situations. As proposed in their paper a car does a lane change to do a takeover maneuver, but the path planning algorithm (MVRRT*) could still be running trying to find a feasible trajectory to come back to the original lane. Meanwhile a car approaching on the takeover lane is not yet being considered in the calculations of the path planning algorithm. This example could quickly lead to a dangerous maybe deadly situation. MVRRT* is of order m{circumflex over ( )}2*log(n) where m is the number of new samples added to a sample.

[0091] Most of the proposed state space exploration algorithms leak on the problem of not knowing the number n (number of states) necessary to solve the reachability problem, only Kloetzer and Calin could answer this problem partially.

(k) Conclusion and Summary

[0092] Some important aspects of the above description is summarized below. An example of the automation of the system development process according to the V-model is summarized with reference to FIG. 18. The basic input data used in the computer-assisted development process are a dynamic model of the mechatronic system (see above, section (b), and FIG. 18, “Model Dynamics”) and a textual system description (see above, section (a), and FIG. 18, “Written Specification”), which is a human-readable text including keywords and text passages linked by the keywords. The keywords represent logic operators and modal temporal operators of a linear temporal logic (LTL).

[0093] The textual system description is automatically decomposed using a computer and software configured to decompose the textual system description into the keywords and the text passages linked by the keywords. The individual text passages (e.g. “traffic light is orange vehicle must stop”) are converted into function definitions (e.g. “traffic_light_is_orange(sensor, vehicle_conditions)”) and the keywords are converted into operators of a linear temporal logic. The functions' return values are Boolean values. Software for parsing and interpreting text is as such known and therefore not further details are discussed here. Once the textual system description is decomposed in keywords (operators) and the functions definitions, an LTL formulae can be derived therefrom. This is also accomplished by a computer and appropriate software. As mentioned above, the LTL formulae is converted into a Büchi automaton. Algorithms for this are also as such known and are implemented in software.

[0094] The dynamic model of the mechatronic system is discretized and the resulting discrete system is also converted into an automaton. Modeling discrete systems using automata is as such known and not further discussed here. Thereby, “conversion into an automaton” means deriving/generating a mathematical model representing the automaton.

[0095] At this point, two automata have been generated. A first automaton representing the textual system description and a second automaton representing the dynamics of the mechatronic system. These two automata can be combined, e.g. by applying a “cross-product” (see above, sections (c), FIG. 18, “Generated Test”). The theory of this cross-product is also known and corresponding citations are provided above. The result is another automaton (test automaton), which may be used for automatic testing when executed by the mechatronic system. During operation of the mechatronic system (e.g. while an autonomous car is driving) the test automaton is able to check the current status of the system for compliance with the requirements/rules specified in the textual system description.

[0096] The mentioned testing automaton executes the functions for which the function definitions have been previously generated automatically as mentioned above. The remaining engineering/development task is the implementation and verification of these functions with specific sensors (e.g. a camera for traffic light detection, whose sensor output is processed by the function traffic_light_is_orange(sensor, vehicle_conditions)).

[0097] Finally, the testing automaton can be automatically converted in a hardware description language (e.g. VHDL, Very High Speed Integrated Circuit Hardware Description Language) and implemented in a programmable logic such as an FPGA (field programmable gate array) or the like. On the target system, the testing automaton is executed, e.g. in the FPGA, and continuously checks the set-points (e.g. a waypoint for an autonomous car) of a controller, which controls the mechatronic system, whether they are compliant with the requirements/rules specified in the textual system description. In fact, the set of controller set-points is limited to those set-points which are detected as compliant with the textual system description.

[0098] Using the concept of computer-assisted development a testing automaton can be generated which is executed—during system operation—on a dedicated piece of hardware (e.g. an FPGA). When designed according to the concept described herein, the testing automaton is able to eliminate controller set-points which are not compliant with the (human-readable) textual system description, which is an important factor for functional safety of a system.

[0099] The software used for parsing the textual system description, the generation of the LTL formulae, the discretization of the system dynamics, the generation of the automata as mentioned above and the combination of the automata to generate the testing automaton, the conversion of the automaton into VHDL may be provided in an integrated development environment which provides all the mentioned software tools, which implement the methods described herein. The mentioned functions, whose definitions result from the textual system description (such as traffic_light_is_orange(sensor, vehicle_conditions)) may be provided in a software library for specific sensors. The performance of the functions in connections with one or more specific sensors (e.g. a camera) may be tested and verified separately. Once the performance of a function and a specific sensor (e.g. a specific camera) has been verified, it can be used in the mechatronic system. The compliance of the overall system is guaranteed by the nature of the design concept. method described herein