CN109791575B

CN109791575B - Automatic design system and method applied to electromechanical system

Info

Publication number: CN109791575B
Application number: CN201780045870.2A
Authority: CN
Inventors: M·纳德希尔
Original assignee: Kotrol Co ltd
Current assignee: Kotrol Co ltd
Priority date: 2016-05-24
Filing date: 2017-05-24
Publication date: 2024-05-14
Anticipated expiration: 2037-05-24
Also published as: CN109791575A; WO2017202906A1; EP3465490A1; US20200320233A1

Abstract

A method for computer-aided system design of a dynamic system is described. According to one embodiment, the method comprises: providing a text system description; converting the text system description into a linear sequential logic LTL equation using a computer; converting the LTL sub-into a first automaton using a computer; providing, using a computer, a second automaton representing a dynamic process of the system; and generating a test automaton by combining the first automaton and the second automaton using the computer.

Description

Automatic design system and method applied to electromechanical system

Background

The present disclosure relates generally to systems and methods for automated design of electromechanical systems.

Background

There are a number of situations in which electromechanical systems are developed and sold that do not meet important safety standards. As the cost and time consumption of development in accordance with suitable safety standards is considerable. Thus, only "high-end" applications, like the aerospace industry, will strictly follow these standards for system design.

Depending on the application, the electromechanical system should be developed according to different safety standards, such as the ISO26262 standard of the automotive industry (titled "road vehicle-functional safety"), the IEC62061 standard concerning mechanical safety (titled "electromechanical safety: functional safety of electrical, electronic and programmable electronic control systems"), the EN51028 standard of the railway industry field, or the D0254/D0178C standard of the aeronautical industry, to comply with the mechanical instructions of E.U, for example. Most of which originate from the meta standard IEC 61508. To do this, the so-called V model is generally a well-known system development process applied to system design (software and hardware design) according to these standards (see fig. 1).

In order to develop and design a V-model compliant system, a significant amount of development time will be required for testing, archiving, and validation. By way of illustration, fig. 2 shows a simplified development process used by the uk aerospace systems company. Typically, the starting point for the workflow is a text demand specification. Next, a software model of the system is built (e.g., using a general numerical computing environment Matlab or Simulink) that meets the requirements specifications. It is verified by inspection that meets the requirements specifications, either by an independent developer in the low critical case of the system (four-eye principle) or additionally by a third party inspector in the high critical case of the system (six-eye principle).

To reduce development costs, mathWorks incorporated several Matlab-based tools that allow for partial automation of the development process. These tools may implement functions including automatic code generation, automatically tracking changes in requirements in the model, automatically testing the design, and automatically verifying and validating the system design. Reviewing the development cycle of the V model (see fig. 1), these tools automate the work of the lower part (three boxes in the next two layers of the V model), as shown in fig. 3. The work above these boxes (three layering of V models from top to bottom) must be done manually by an engineer "manual".

Disclosure of Invention

A method of computer-aided system design for a dynamic system is described herein. According to one embodiment, the method comprises: providing a text system description; converting the text system description into a linear sequential logic LTL type by using a computer; converting the LTL sub-into a first automaton using a computer; providing, using a computer, a second automaton representing a system dynamics; and generating, using the computer, a test automaton by merging the first and second automatons.

The method described herein allows for the partially automatic design and validation of a system according to the well known V model. In one example, the method may further comprise: generating a Hardware Description Language (HDL) model of the test automaton; and uses a computer to implement an automatic test automation process on hardware. In one example, the textual system description may be automatically enhanced to include redundancy.

Converting the text system description into an LTL form includes the steps of: decomposing the text system description into keywords representing logical operators and modal timing operators of Linear Timing Logic (LTL), and text channels connected by the keywords; generating, using a computer, a software function (function) definition corresponding to a text passage connected by a keyword; LTL equations are generated based on a plurality of software function definitions and operators defined by keywords. In one example, the process of providing a second automaton representing system dynamics includes: providing a model representing the dynamics of the system; discretizing the model to obtain a discrete model; and converting the discrete model into an automaton. How the above-described discretization process is accomplished will be described in detail by different schemes.

Further, a controller module for application to a dynamic system is also described. According to one example, the controller module includes a controller unit that performs controller tasks to control the dynamic system, a hardware unit that performs the test automaton designed by the method summarized above, and at least one sensor that acquires sensing information. The controller unit provides the one or more set points to the hardware unit, which is configured to verify whether the one or more set points conform to the textual system description based on the sensor information.

The method summarized above may be implemented in the form of a software product, which when run on a computer performs the method.

Drawings

The invention may be better understood with reference to the following description and the accompanying drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. Furthermore, in the drawings, like reference numerals designate corresponding parts throughout the several views. In the drawings:

Fig. 1 shows a V-model for an electromechanical application.

Fig. 2 shows a simplified workflow designed according to a V model as proposed by john russell of the aerospace systems company in the united kingdom at the Matlab exhibition in 2015.

FIG. 3 shows the use ofThe company provides tools to automate the working steps of the lower part of the V-model, here indicated by green boxes.

Fig. 4 illustrates the degree of automation that can be achieved by the methods described herein.

Fig. 5 graphically illustrates an example of a system specification.

FIG. 6 illustrates different function headers generated by function nontranslatable text.

Fig. 7 shows the result of the process of converting two formulas into an automaton.

Fig. 8 shows the result of linearization of a nonlinear system.

Fig. 9 shows the result of the environment-driven discretization.

The figure xx shows different representative forms of polyhedrons.

Fig. 10 is an example of a conversion system as shown in wikipedia.

Fig. 11 illustrates an exemplary conversion matrix of the conversion system of fig. 10.

FIG. 12 illustrates different approaches to representing environment-based discretization.

Fig. 13 shows an automaton applied to the above-described dynamic discretization based on a controller.

Fig. 14 shows an exemplary scenario to be tested.

Fig. 15 shows the verification result of the different waypoints WP1 … WPn.

Fig. 16 shows the integration of the camera, OBD device and function.

Fig. 17 shows a possible integration test of the camera that can detect traffic lights.

Fig. 18 summarizes the automated development process of an exemplary electromechanical system (e.g., an autopilot).

Detailed Description

With the methods and systems described below, it is possible to implement (semi) automation of the process already described in the background section, to further reduce the cost of the V model development cycle. Fig. 4 illustrates the degree of automation that can be achieved by the methods described herein.

(A) Language translation and description gives a text as a description defining the behavior of the vehicle. For example (see fig. 5):

● The vehicle is started at (1),

● The vehicle is always in the stay outside (environment)

● Vehicle always avoid barrier to the right (3)

● The vehicle is driven to (4) and the specifications may further include traffic rules provided within the applicable laws and regulations.

● If there are traffic lights then the rules of the traffic lights are followed,

If the traffic light is a red light, the vehicle must stop,

If the traffic light is an orange light, the vehicle should stop,

If the traffic light is green, the vehicle may travel,

If the traffic light flashes orange, the vehicle may,

Text may be presented in paragraphs or small segments.

The next step is to analyze the impact of a system crash that may occur for each line of text above. ISO61508 and other similar standards use so-called failure mode and impact analysis (FMEA) or similar techniques to establish critical levels of text lines. Depending on the criteria used, risk Priority Numbers (RPNs) may be used. The procedure for obtaining the RPN depends on the criteria used, which can be found according to the relevant criteria and will not be discussed here.

The result of the FMEA analysis is a test and test requirement and/or critical level and/or other factors that must be considered in the function design process. The test and test requirements define, for example, the detection speed or the accuracy of a function to be tested (including the sensor) so that the function can be regarded as being sufficiently safe to apply to the system. This is particularly important for integrated testing (as will be explained further below). The critical level can provide suggestions for the design of the function, such as that the function must be redundant and the system architecture of the design must provide corresponding redundancy.

After applying the procedure described above, each statement will include part of the information about the necessary tests and their test requirements and suggested system structure, which will be stored in a form similar to the following:

the vehicle must stop when in red light; redundancy; detecting the speed of le-3; …; …;

two texts are used as requirements, which are used in a written manner, but are modified word by word when applied to linear sequential logic (LTL) and its extensions. Similar phrases are

● Non-ferrous metal

● Or (b)

● And (3) with

● Always

● Final result

● Next step

●…

Applying the phrase in the above example can produce the following result

The vehicle always stays at

In the outside

And (3) with

Obstacle avoidance rightward (3)

And (3) with

Traveling at a speed of not more than 50 km/h

And (3) with

Compliance with traffic light regulations

The vehicle must stop when the light is red

Or (b)

The vehicle should stop when the yellow light is on

Or (b)

The vehicle must travel at green light

Or (b)

Normal traffic regulations are complied with when traffic lights are not in operation

In the following case, the program will use this information to add these requirements to the text, where the information in one sentence requires redundancy or there is a special system design in the next step. These additional requirements must follow the relevant standards (e.g. IEC 61508). As a simple example, the redundancy process of the "red light" statement can be described with reference to the above example. The results after treatment were similar to:

Vehicles always

Stay in the outside

And (3) with

Obstacle avoidance rightward (3)

And (3) with

Traveling at a speed of not more than 50 km/h

And (3) with

Compliance with traffic light regulations

The vehicle must stop at red light

The vehicle must stop at 1 when red

Or (b)

The vehicle must stop at red light 2

Or (b)

The vehicle should stop when the yellow light is on

Or (b)

The vehicle must travel at green light

Or (b)

Therefore, all the statement lines of non-keywords need to be converted into function definitions by an application (see fig. 6). The function definition can be generated by any programming language, such as C/C++ or a high-level programming language, such as Matlab/Simulink. In the next step, the convertible document is converted into LTL expression by using pattern matching and combined with the result of the function term. Referring to FIG. 6, a sub-paragraph is written as

LTL＝res1∧res2∧res3∧res4

And the second is

res3＝(res3_1∨res3_2∨res3_3∨res3_4)

If a keyword is found, the keyword is replaced with a corresponding function operator (NOTOR (v), AND (v), ALWAYS (G), eventully (F), NEXT (X), etc. The resulting LTL-form is then converted into a Buchi automaton (e.g. Buchi automaton is an omega-automaton that extends a finite automaton to finite inputs) or similar state machines using the proposed method, e.g. one of the following internet disclosures:

https:// en.wikipedia.org/wiki/Linear temporal_logic_to_b% c3% BCchi _ automaton or-http:// www.lsv.ens-cachan.fr/-gastin/ltl 2 ba%

The above steps are illustrated graphically in fig. 7 for a better understanding. There is also a possibility that some keywords appear in some non-translatable (translatable) statement lines. This may be considered in future applications.

(B) Mathematical model

On the other hand, a mathematical model of nonlinear dynamics is given.

Discretization of the dynamic model also yields an automaton (state machine). Discretization may be accomplished in different ways. The most common and popular method of discretizing the system is to use Jacobi Matrix (Jacobi Matrix) to linearize the overall nonlinear dynamic process. The result of the discretization is a automaton in the time domain, wherein the discrete states of the automaton are discrete time stamps and the hopping function is the sampling time. Fig. 8 shows the result of discretization.

Another approach is the discretization of the environment drive, where the working area is divided into different sub-areas, as shown in fig. 9. The individual sub-regions may be marked as occupied or unoccupied. In fig. 9, the region is represented by a polygon, wherein one discrete state q _i is represented as the center of the polygon. Page 11 of publication M.Althoff,Reachability Analysis and its Application to the Safety Assessment of Autonomous Cars,PHD-thesis,TU Miinchen,2010, shows different representations of a polyhedron, a polyhedron based on a line half-space (H-) representation or a vertex (V-) space representation. There are other ways to represent a polyhedron (see fig. 10).

The various states within the same discrete (sub) region are the same (e.g., unoccupied, occupied, etc.). The discrete automaton may in turn be viewed as a system of transformations from one discrete point to another, and may be represented by a transformation matrix. Fig. 10 represents three discrete state conversion systems q ₁＝l,q₂ =2 and q ₃ =3. The hopping function (i.e. the transfer function) is the distance between the discrete states, which is a predefined scale criterion (0 may also be used to indicate that there is no connection between two discrete states, 1 for a connection, however a value between 0 and 1 indicates the probability, indicating the possibility). Fig. 11 shows a conversion matrix of the conversion system in fig. 10.

Other ways of discretizing the operating environment (working area) are also possible. For example, discretization of an environment-driven nonlinear dynamic process may be represented by a number of circles (which surround occupied portions in the environment) that originally define a radius. The discrete environment shown in FIG. 12 is

q₁\(q₂∩q₃∩q₄)

The following steps may be applied to complete a controller-based or behavior-based discretization process. Here, a general differential equation is used to describe a discretization process of a vehicle like an airplane or a vehicle. In the literature, this is also referred to as "durian car".

ω＝[ω_min,0,ω_max]

v＝[v_min,0,v_max]

u＝[v，ω]

In the following case, the discrete automaton can be defined as (see FIG. 13)

●ω＝ω_min＜0...q₁＝left

●ω＝0...q₂＝straight

●ω＝ω_max＞...q’＝right

The discrete conversion function may be defined according to a metric or based on a physical, graphical or random function. It is also possible to use the discretized v and ω in a previously defined discretization step n _dist, in this way

(C) Automatic test generation

Applying a vector product to two automata (state machines) provides a new state machine that is an automatically generated test, also known as validation, as shown in fig. 4. If the automaton's result is positive, then the verification result is also positive, meaning that the model's automaton meets the requirements. The mathematical background of the vector product can be found in page 11 of the following disclosure ：Bruno Filipe Araujo Lacerda,"Linear-Time Temporal Logic Control of Discrete Event Systems",Master Thesis,Universidade Technica de Lisboa,Sept.2007.

It is also possible to complete verification using only one state, in addition to all discrete states of all state machines of the model.

(D) Code generation to automatically generate test and deployment on target hardware

The program in turn uses the resulting state machine to automatically generate it as C/C++ or Verilog/VHDL code or other programming language. Verilog/VHDL is used to speed up the verification process. Source code is applied to the FPGA using standard FPGA development programs.

(E) Execution of functions

After the function interface is generated, the function must be executed so that the behavior of the function satisfies the written statement. Typically this is done in a simulation environment like Matlab. As an example, look at the following sentence:

Obstacle avoidance rightward (3)

This statement means that the automated system must avoid obstacles to the right (which is also a major behavioral requirement of the rules in air to incorporate the UAV into civilian airspace). As shown in fig. 14, the question that has to be solved is which one of WP1 to WPn is selected to satisfy the written sentence. Thus, the function must contain a test that produces a positive result to the right to avoid a vehicle collision. To achieve this, the function requires relevant information: distance to the obstacle, speed and direction of the vehicle, dynamic behavior of the vehicle (steering radius related to speed) and information whether the waypoint WPi is reachable.

The accessibility of the waypoints WPi may be calculated by different methods. One such method is to use the symbolic availability result of a Dubin (Dubin) automobile, as shown on page 28 of the following disclosure ：Matthias Althoff,Reachability Analysis and its Application to the Safety Assessment of Autonomous Cars,PHD-thesis,TU Mtinchen,2010,and publication Marius Kloetzer,Symbolic Motion Planning and Control,PHD-thesis,Bostion University,2008.

Assuming that some method has now been performed to solve the accessibility problem for a given dynamic process, tests are also performed in the program to calculate the result, as shown in fig. 15. The red dots in the figure represent possible path points that do not meet the requirement that the vehicle should avoid the obstacle to the right, while the green dots (marked with arrows) represent that they meet the above requirement.

The generated function will use as input a sensor that is able to detect obstacles and the speed, direction and steering angle of the vehicle. The function returns results in a return value manner

● If the path point does not meet the specification, it is expressed as 0 (red point)

● The minimum and maximum values that the function can return to the speed of the vehicle and the set point of the steering angle controller are additionally represented by 1 (green dot) if the waypoint meets the specification.

(F) Code generation and testing of functions

In the next step, the high-level coding functions developed in the last step will automatically be generated as source code that the target development board can use. In addition, the testing of the module will be automatically generated to test the automatically generated source code for high-level function functions. The test may include:

● The function of the test is to be tested,

● The black box is used for testing the black box,

● The probability of a test of the probability that the current,

● The interface is tested in such a way that,

● The performance of the test piece was tested in the same manner,

● The software is tested in a loop.

These test-to-code generated functions are then applied and compared to high-level code functions.

(G) Integrated testing

As described above, the requirements of each function are defined either by the customer or by FMEA analysis. An integration test is required to verify that the subsystem is satisfactory. Fig. 16 shows the integration process of the camera as an OBD device binding function (e.g., function, traffic_light_is_orange (sensor, vehicle_status)).

Fig. 17 shows a potential setup for an integrated test of a camera that should detect orange traffic lights. The traffic lights are displayed on the screen in different sizes to simulate the situation of different distances of the traffic lights from the camera. Noise added to the simulated traffic light is generated using a stochastic model to simulate external conditions. The camera is mounted on the test device and directed towards the screen. The acquired plurality of images are forwarded to a traffic lamp orange function and the output result of the function is forwarded. The test computer calculates the number of detections. The test is repeated until the necessary number of tests is reached. The achieved detection speed is compared with the required detection speed. In the event that the detection speed is below the required detection speed, the subsystem will be installed into an automated system ready for use. In the case of failure, the subsystem needs to be tuned and the V model repeated.

(H) Adjustment of

If the condition that the existing specification does not cover occurs in the running process, the special condition specification is added into the existing specification. The entire development process according to the V model setting is repeated so that the automatic system can cope with special cases.

(I) Deployment to a system

Automatically generated VHDL/Verilog code and tested subsystems are deployed into an automated system. Each subsystem outputs results to the state machine for verification.

(J) Scientific background

Claire Tomlin et al (Tomlin,Claire,Ian Mitchell,Alexandre.M Bayeny Meeko Oishi,2003,Computational Techniques for the Verification of Hybrid Systems,Proceedings of the IEEE,pp.986-1001) outline reachability analysis based on state space exploration as a primary tool for validating hybrid systems. Hybrid systems are systems that combine discrete dynamic processes and continuous dynamic processes into one model. Methods for solving the reachability problem can be classified into overapproximation (approximation methods and convergence approximation) methods.

Overapproximation methods attempt to effectively overapproximate the reachable set, while state representations typically scale polynomials with a continuous state space dimension n, with some exceptions. Such an approach has significant advantages over other approaches because the execution time and the amount of memory required generally have a linear relationship with the size of the representation of the reachable state. On the other hand, the same disadvantage exists in that the method is not accurate enough to satisfy a nonlinear dynamic process, the shape of the set of reachable points of which is not polygonal or elliptical.

The convergence approximation method attempts to represent the reachable set as close as possible, while the state representation scales exponentially with n. This results in that these methods are not practical for sizes (dimensions) greater than 5, but have the advantage that nonlinear dynamic processes can be covered and they do not make assumptions about the shape of the set that is reached.

Matthias Althoff(Matthias Althoff,Reachability Analysis and its Application to theSafety Assessment of Autonomous Cars,phd-thesis,TU München,2010) The concept of overapproximation is used and applied to nonlinear systems by linearizing them around the operating point and integrating them. He describes the reachable set of systems using polygons after each integration step. He extends this concept to so-called random state security verification, he proposes to extract the markov chain from the initial hybrid dynamic process. This is done by discretizing the continuous dynamic process such that the state space region is defined as the discrete states of the Markov chain. The advantage of this method is that it makes it possible to obtain a control strategy that minimizes the risk of collisions, while it also has drawbacks: the number of discrete states increases exponentially with the number of continuous states. Over the past few years, he applied this technique to different applications, such as security verification of e.g. autopilot cars or automatic landing helicopters.

The methods described so far have all been used to solve the typical robot navigation problem "from point a to point B and avoid collisions". Such a specification may be expressed using an inequality, for example, as a circle around an accessible point or a circle around a point that should be avoided. More expressive specifications such as "always avoid right collisions" (as described in the air rules) may be of interest.

Marius Kloetzer and Calin Balta (see Marius Kloetzer,Symbolic Motion Planning and Control,phd-thesis,Bostion 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) for two approaches, focusing on more expressive specifications rather than on state space exploration, but on environment-driven discretization, also referred to as top-down approach and controller-driven discretization, also referred to as bottom-up approach).

Luis Reyes Castro et al (Luis L 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),2013IEEE 52nd Annual Conference on,3217-3224) perhaps demonstrate for the first time the implementation of a validation control algorithm that is capable of handling safety regulations (road regulations) while achieving risk control within a given reach. The proposed solution is based on a fast search random tree (RRTs) algorithm that gradually designs feasible trajectories for real-time applications. Since the proposed method is iterative, it is easy to understand that the actions are still running when performed, with the result that very dangerous situations can result. As proposed in their papers, a car performs lane changes to take over operations, but the path planning algorithm (MVRRT x) may still be running and attempt to find a viable path back to the original lane. Meanwhile, a vehicle approaching the take-over lane is not considered in the path planning algorithm. This example may quickly lead to a situation where the hazard may be fatal. MVRRT is ordered by m 2 log (n), where m is the number of new samples added to the sample.

Most of the proposed state space search algorithms expose a question that is not aware of the value n (state number) necessary to solve the accessibility problem, only Kloetzer and Calin can answer this question in part.

(K) Conclusion and summary

Some important aspects described above will be summarized below. Referring to FIG. 18, an example of system development process automation according to the V model is summarized. The basic data used in the computer-aided development process is a dynamic model of the electromechanical system (see section (b) above and "dynamic model" in fig. 18) and a textual system description (see section (a) above and "written specification" in fig. 18), which are human-readable words, including keywords and word channels linked by keywords. Keywords represent logical operators and temporal operators in the form of linear sequential logic (LTL).

The textual system description is automatically parsed by a computer and software configured to parse the textual system description into keywords and text channels connected by the keywords. Each individual text channel (e.g. "vehicle must stop when traffic light is orange") is converted to a function definition (e.g. "traffic_light_is_orange (sensor, vehicle_status)) and the key is converted to an operator of the linear sequential logic. The function returns the result in the form of a boolean value. Software for parsing and interpreting text is known and therefore further details will not be discussed here. When the text system description is decomposed into keywords (operators) and function definitions, the LTL expression can be derived therefrom. Or by a computer and suitable software. As described above, the LTL sub-conversion is a Buchi automaton. Such algorithms are known and have been implemented on software.

The dynamic model of the electromechanical system is discretized and the resulting discretized system is also converted into an automaton. The use of automata for discrete system modeling is known and will not be discussed further herein. Thus, converting to an automaton means deriving/generating a mathematical model that is represented as an automaton.

At this point, two automata have been generated. The first automaton represents a textual system description and the second automaton represents a dynamic process of the electromechanical system. The two automata may be combined, for example, by applying a "cross product" (see section (c) above, and "generate test" in fig. 18). The theory of this vector product is known and corresponding references are provided above. The result is another automaton (test automaton) that can be used to perform automated testing when executed by an electromechanical system. During operation of the electromechanical system (e.g., while the autopilot is traveling), the test robot is able to detect the current state of the system so that it complies with the requirements/rules set forth in the text system description.

The mentioned test automaton performs a function, the definition of which has been automatically generated in advance, as mentioned above. The remaining engineering/development task is to perform and verify these functions by means of special sensors (e.g. cameras for traffic light detection, the output of which is handled by the function traffic_light_orange (sensor, vehicle_status)).

Finally, the test automaton may be automatically converted to a hardware description language (e.g., VHDL, very high speed integrated circuit hardware description language) and executed in a programmable logic device, such as an FPGA (field programmable gate array) or similar device. The test automaton is executed in the target system (e.g., in an FPGA and constantly detects whether the set point of the controller controlling the electromechanical system (e.g., the waypoint of the autonomous car) meets the requirements/rules set forth in the text system description. In fact, the set of points of the controller are limited to those set points that conform to the textual system description.

Using the concept of computer-aided development, a test automaton executing on dedicated hardware (e.g., an FPGA) can be generated while the system is running. When designed according to the concepts described therein, the test robot is able to exclude those setpoints that do not meet the (human-readable) textual system description, which is important for functional safety of the system.

The software used to analyze the textual system description, the generation of LTL equations, the discretization of the system dynamics, the generation of automata as described above, and the incorporation of automata to generate test automata, the conversion of automata to VHDL, may be provided in an integrated development environment containing all of the software tools involved, which execute the methods defined therein. The mentioned functions, the definition of which is derived from the text system description (e.g. traffic_lamp_orange (sensor, vehicle_status)) may be provided in a software library in some special sensors. The performance of the function in connection with one or more sensors (e.g., cameras) may be tested and verified separately. The function and the performance of a specific sensor (such as a specific camera) can be applied to an electromechanical system after verification. Compliance of the overall system is ensured by the nature of the design concept and the methods described therein.

Claims

1. A method for computer aided system design:

Providing a text system description;

converting the text system description into a linear sequential logic LTL equation using a computer;

Converting the LTL sub-into a first automaton using a computer; providing, using a computer, a second automaton representing a dynamic process of the system;

And generating a test automaton by using a computer by combining the first automaton and the second automaton.

2. The method of claim 1, further comprising:

Generating a Hardware Description Language (HDL) model of the test automaton;

the test automaton is executed in hardware using a computer.

3. The method of claim 1 or 2, wherein converting the textual system description to LTL form comprises:

Decomposing the text system description into keywords representing logical operators and modal timing operators of Linear Timing Logic (LTL), and text channels connected by the keywords;

generating a software function definition corresponding to the text channel connected by the key words by using a computer;

the LTL equation is generated based on the software function definition and operators defined by keywords.

4. The method of claim 1, wherein providing a second automaton representing the system dynamic process comprises:

Providing a model representing the dynamic process of the system; discretizing the model to obtain a discrete model;

the discrete model is converted to an automaton.

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

6. A controller module for controlling a dynamic system, the module comprising:

A controller unit for performing controller tasks to control the dynamic system, a hardware unit for performing a test automaton designed according to the method of any of claims 1 to 5;

At least one sensor for acquiring sensing information,

Wherein the controller unit provides one or more set points to the hardware unit, the hardware unit being configured to verify whether the one or more set points conform to the textual system description based on the sensory information.

7. A computer storage medium having stored thereon computer instructions which, when executed on a computer, cause the computer to perform the method of any of claims 1 to 5.