Application of Giotto software in real-time embedded control

With the rapid development of computer technology, control technology, and information technology, industrial production and management methods have entered the era of production automation and intelligent control. In particular, the application of distributed embedded systems requires standardized, real-time control modules and I/O function modules for system integration and the construction of complex distributed systems that are suitable for harsh environments. Real-time embedded software modules are suitable for designing complex distributed systems. They support the system modeling and construction of distributed and heterogeneous devices. The role of embedded modules is to provide structures and technologies that make complexity easy to handle. Giorio-based embedded control devices are more suitable for applications with hard real-time control constraints. In this article, the platform refers to the hardware structure, operating system, and communication protocol, which consists of CPU, sensors, actuators, and networks. Platform-independent events include application functions and time limits, and platform-related events include timing scheduling, communication, and physical characteristics.

1 Giotto programming features

Traditional real-time embedded software design is based on abstract mathematical models. Control engineers use software tools to solve models according to object behavior and environmental impact to obtain the model's functions and performance, and then hand it over to software engineers to write code for a given platform, and test and optimize the code on the given platform until a satisfactory time behavior is obtained. In this process, the close correspondence between the model and the code is often lost, the software's complexity is abandoned, and the complexity of software design is increased. As a result, the resulting software is weakened and difficult to apply on different platforms.

The embedded control software design based on Giotto separates the functional program from the specific platform and the time limit from the function. Its platform independence makes it have better real-time performance, reliability and reusability, and is more suitable for embedded real-time distributed systems. Figure 1 is a design flow chart of an embedded control system based on Giotto. First, the control engineer and the software engineer reach an agreement on the function and time limit of the control design and design a Giotto program; then, the software engineer uses the Giotto compiler to generate an executable code that can connect to the Giotto runtime library and map the program to a given platform. The Giotto runtime library provides an intermediate layer for timing arrangement and communication, which defines the interface between the Giotto executable program and the platform. A Giotto runtime library has been established for Wind River's VxWorks real-time operating system on Intel x86 machines.

2 Giotto Programming Technique

Giotto is a platform-independent, high-level programming language for specific control applications. Giotto is designed for demanding control applications that require periodic access to sensors, calling of tasks, update of execution, and mode switching. Giotto is based on time-triggered programming, and the communication from sensor to CPU and from CPU to actuator is triggered by a global clock, making it predictable. Giotto programs do not specify platform-related parts, such as priority, communication, etc. Its advantage is that it is independent of the specific execution platform and is compatible with any real-time operating system, scheduling algorithm, and real-time communication protocol.

The two core components of Giotto are periodic task calls and mode transitions. A Giotto program specifies a series of modes, each of which contains a series of tasks and mode transitions. At each moment, the program is executed in a specific mode P. Each P mode transition contains an evaluation function and a target mode Q. The system will only switch to the new mode Q when the evaluation function is true.

The Giotto task is a periodic task, and its input and output ports are updated at the start and end of the task cycle, respectively. However, the Giotto task does not necessarily have to be started at the beginning of the cycle, but only needs to be started and completed within the cycle. Figure 2(a) shows the timing of a 40ms task M and a 10ms task N running on the same CPU. The dotted line is the possible situation of the current task occupying the CPU. At 0ms, both M and N read the values ​​of their input ports; at 10ms, the calculation result of task N is written to its output port, but N has already finished executing (as shown by the dotted line in the figure); at 40ms, the calculation result of task M is written to its output port, but task M has completed execution before 40ms. Regardless of whether task M completes its calculation at any time between 0 and 40ms, task N will only read its result at 40ms.

In Giotto, a task can be viewed as a unit of work that must be completed once it is started. A mode transition cannot terminate any task before the task cycle ends. Given a Giotto mode P (including Giotto tasks M and N called by 40 ms and 10 ms, respectively) and a Giotto mode Q (including Giotto tasks M and R called by 40ms and 5ms, respectively). Figure 2(b) shows the timing of the activation of the mode transition at the 10th ms in mode P, when mode P is converted to mode Q. Since both P and Q contain task M, task M will not terminate, but task N is replaced by task R with a period of 5ms. [page]

3. Design of autonomous vehicle for logistics system

The 2-autonomous car system includes 2 autonomous cars, each of which contains a microprocessor, a motor and a touch sensor. It is assumed that only one autonomous car is the leader at any time, and the other autonomous cars are followers. Among them, the autonomous car in the leading or avoiding state is called the "leader", and the autonomous car in the following or stopping state is called the "follower". When the leader is blocked, the leader enters the avoiding state and the follower enters the stopping state. The autonomous car entering the avoiding state executes an avoiding procedure to avoid obstacles, and the autonomous car in the stopping state still stops; when the leader completes the avoiding procedure and returns to the leading state, the follower returns to the following state. When one of the followers is blocked, the autonomous car enters the avoiding state, and all other autonomous cars enter the stopping state, and the blocked autonomous car becomes the new leader. Figure 3 shows the state behavior of the 2-autonomous car system.