EP4670034A1

EP4670034A1 - SYSTEM AND METHOD FOR GENERATING CONTROL APPLICATIONS ON REAL-TIME PLATFORMS

Info

Publication number: EP4670034A1
Application number: EP23719167.1A
Authority: EP
Inventors: Tao CUI; Michael Epp
Original assignee: Siemens AG; Siemens Corp
Current assignee: Siemens AG; Siemens Corp
Priority date: 2023-03-30
Filing date: 2023-03-30
Publication date: 2025-12-31
Also published as: WO2024205585A1; CN120958431A

Abstract

A method for implementing a real-time controller for an automation system includes starting a code generator to transform a model representation of a controller into controller code for execution on a target device operating on an open real-time platform. A configuration specification is read by the code generator, which includes data definition mapped to an input and output in the model representation of the controller and execution definition specifying a real-time requirement for execution on the target device. The configuration specification is parsed by the code generator to generate interface code configured to use an API provided by an inter-app communication layer in the target device based on the data definition, and to use an API provided by a real-time execution service running on the target device based on the execution definition. The controller code and interface code are linked to generate a control app deployable on the target device.

Description

SYSTEM AND METHOD FOR GENERATING CONTROL APPLICATIONS ON

REAL-TIME PLATFORMS

TECHNICAL FIELD

[0001] The present disclosure generally relates to industrial automation systems. In particular, disclosed embodiments relate to methods and systems for engineering and executing control loops with advanced control applications on open real-time platforms that enable software-defined automation, hard-ware independent engineering and support for third-party applications.

BACKGROUND

[0002] Programming of control devices for industrial automation typically imposes a number of requirements on the used software and hardware platform, such as real-time capability, security and stability, and reliability. These requirements usually constitute the backbone of the engineering of many devices and applications. To accommodate such requirements, specialized real-time operating systems (RTOS) and interfaces are often adopted by many automation systems to ensure a flawless operation. However, such specialized RTOS and interfaces can often limit a user’s options of customizing and extending a device’s functionalities. Such limitations can arise, for example, by restrictions of software, hardware-specific programming, or restricted access to certain parts of the operating system.

[0003] In modern times, however, it is an increasing trend for automation system users to demand for more flexibility in automation. It is desirable to have automation systems with an open framework that also allow control applications to be written in a language of choice, allowing the automation system user to incorporate tools and frameworks of third-party vendors to be used in their automation projects.

[0004] However, accomplishing the above objectives can require tedious integration efforts which can create significant overhead on the engineering side. Furthermore, the development and integration processes can lead to individual and often non-standard solutions to similar problems, creating an inconsistent and non-transparent ecosystem of apps and programs. This can make it difficult to maintain and expand the automation system. Improved systems are desirable. SUMMARY

[0005] Briefly, aspects of the present disclosure are directed to a solution that addresses at least the above-described problems to provide flexibility in an automation system. The solution is realized by providing an open real-time platform on a target device and a mechanism for automatically generating code for a control app that can utilize application programming interfaces (APIs) provided by the open real-time platform to execute control loops on the target device.

[0006] A first aspect of the disclosure is directed to a method for implementing a real-time controller for an automation system. The method is performed by a computing system and comprises starting a code generator to transform a model representation of a controller into controller code to be executed on a target device. The method further comprises reading a configuration specification by the code generator. The configuration specification includes data definition mapped to an input and output in the model representation of the controller and execution definition specifying a real-time requirement for execution on the target device. The method further comprises parsing the configuration specification by the code generator to generate interface code configured to use an API provided by an inter-app communication layer in the target device based on the data definition, and to use an API provided by a real-time execution service running on the target device based on the execution definition. The method further comprises linking the interface code with the controller code by the code generator to generate a control app for deployment on the target device. The deployed control app is configured to interact, using the interface code, with the inter-app communication layer and the real-time execution service on the target device to execute control loops.

[0007] Further aspects of the disclosure are directed to a corresponding computing system and to a computer program product including instructions executable by a computing system to perform the above-described method.

[0008] Yet another aspect of the disclosure is directed to an automation system. The automation system comprises a controller for controlling a physical device. The controller includes a computing device having an open real-time platform that comprises: an inter-app communication layer providing one or more APIs usable by multiple processes running on the controller for standardized communication between the processes, and a real-time execution service providing one or more APIs usable by the multiple processes to coordinate execution of control loops based on a real-time requirement. The automation system further comprises an engineering system. The engineering system comprises one or more processors, and a non-transitory memory storing instructions executable by the one or more processors to generate a control app by a method as described above, for deployment on the controller. The deployed control app is thereby configured to utilize the APIs provided by the inter-app communication layer and the real-time execution service to execute control loops on the controller.

[0009] Additional technical features and benefits may be realized through the techniques of the present disclosure. Embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed subject matter. For a better understanding, refer to the detailed description and to the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The foregoing and other aspects of the present disclosure are best understood from the following detailed description when read in connection with the accompanying drawings. To easily identify the discussion of any element or act, the most significant digit or digits in a reference number refer to the figure number in which the element or act is first introduced.

[0011] FIG. 1 illustrates a computing system that can support engineering of an advanced control app for an open real-time platform, according to an embodiment.

[0012] FIG. 2 illustrates a process flow for automatically generating a control app for deployment on an open real-time platform, according to an embodiment.

[0013] FIG. 3 illustrates an architecture of an open real-time platform in a target device wherein a control app generated according to disclosed embodiments may be deployed.

[0014] FIG. 4 illustrates a non-limiting example use-case of an automated guided vehicle (AGV) with an embedded real-time controller implemented based on disclosed embodiments.

[0015] FIG. 5 is a high-level block diagram of a model representation of a controller created using Simulink®, for the non-limiting use-case shown in FIG. 4. [0016] FIG. 6 is a schematic diagram illustrating inter-app communication on the target device for executing a control loop in the non-limiting use-case shown in FIG. 4.

DETAILED DESCRIPTION

[0017] FIGS. 1 through 6, discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged device. The numerous innovative teachings of the present disclosure will be described with reference to exemplary non-limiting embodiments.

[0018] To increase flexibility in automation, disclosed embodiments realize an open ecosystem enabling software-defined automation, hardware- independent engineering and support for third-party applications. Disclosed embodiments can leverage the availability of powerful and open CPU hardware to allow a user to have their own control applications, which can include advanced numerical computation engines, running inside a control loop. In particular, disclosed embodiments can address a technical problem that arises in an open ecosystem on how control engineers can efficiently integrate such control applications into real-time controllers, such that: (i) engineers can choose and select the best tools or languages suitable for a control task to develop a control application (e.g., using advanced tools such as Matlab®, a product of MathWorks Corporation), (ii) real-time cyclic operation and determinism is met for user-defined control loops, and (iii) interoperability is achieved between the control application and other components of the open ecosystem (e.g., native apps).

[0019] Disclosed embodiments can furthermore leverage the evolution of more and more general- purpose operating systems (such as Linux) towards real-time industrial applications. For example, the real-time patch PREEMPT-RT has now become part of the mainline Linux kernel. However, there are still many technology gaps even with such operating systems. For example, there may not be a centralized clock service, predefined real-time properties or standardized ways of monitoring realtime applications by the operating system, meaning that applications may not be able to react on realtime violations. Disclosed embodiments can fulfill one or more of these technology gaps.

[0020] Disclosed embodiments are based on the implementation of an open real-time platform on a target device, which can be a general-purpose edge computing device (e.g., a PC-based controller operating on Linux). The open real-time platform can be realized by an inter-app communication layer with APIs for interoperability and standardized communication between different apps/processes, and a real-time execution service for ensuring determinism in real-time operation with APIs across the different apps/processes. Disclosed embodiments further provide a mechanism for automatically generating code for a control application (referred herein as “control app”) that can use the above- mentioned APIs provided by the open real-time platform to execute control loops. The automatic code generation process can effectively handle the integration of the control app with other components of the open ecosystem.

[0021] Disclosed embodiments can thus enable engineers to develop control apps with tools or frameworks of their choices without tedious ad-hoc integration. Engineers can rely on a robust and well-tested environment which standardizes communication between apps and provides real-time determinism, and thereby enables the support for third party applications. Engineers can therefore choose the best tools/frameworks to design more powerful control apps for complex control tasks, and readily implement these apps into the automation system, which can now behave as native apps, while keeping the system easy to maintain and expand.

[0022] Turning now to the drawings, FIG. 1 illustrates a computing system 100 in which an embodiment can be implemented. The computing system 100 can be, for example, part of an engineering system for industrial automation. Such an engineering system may be particularly configured by software or otherwise to perform the processes as described herein, and in particular as each one of a plurality of interconnected and communicating systems as described herein to implement an industrial automation system. The computing system 100 depicted includes one or more processors 102 connected to a level two cache/bridge 104, which is connected in turn to a local system bus 106. Local system bus 106 may be, for example, a peripheral component interconnect (PCI) architecture bus. Also connected to local system bus in the depicted example are a main memory 108 and a graphics adapter 110. The graphics adapter 110 may be connected to display 111.

[0023] Other peripherals, such as local area network (LAN) / Wide Area Network / Wireless (e.g., Wi-Fi) adapter 112, may also be connected to local system bus 106. Expansion bus interface 114 connects local system bus 106 to input/output (I/O) bus 116. I/O bus 116 is connected to keyboard/mouse adapter 118, disk controller 120, and I/O adapter 122. Disk controller 120 can be connected to a memory 126, which can be any suitable machine usable or machine readable storage medium, including but not limited to nonvolatile, hard-coded type mediums such as read only memories (ROMs) or erasable, electrically programmable read only memories (EEPROMs), magnetic tape storage, and user-recordable type mediums such as flash drives, hard disk drives and compact disk read only memories (CD-ROMs) or digital versatile disks (DVDs), and other known optical, electrical, or magnetic storage devices. I/O adapter 122 can be connected to control, read from, write to, or otherwise communicate or interact with any number of external devices.

[0024] Also connected to I/O bus 116 in the example shown is audio adapter 124, to which speakers (not shown) may be connected for playing sounds. Keyboard/mouse adapter 118 provides a connection for a pointing device (not shown), such as a mouse, trackball, trackpointer, touchscreen, etc.

[0025] LAN/ WAN/Wireless adapter 112 can be connected to a network 130 (not a part of computing system 100), which can be any public or private computing system network or combination of networks, as known to those of skill in the art, including the Internet. Computing system 100 can communicate over network 130 with a target device 140 to transport a control app 162 generated by the computing system 100. The target device 140 may not be part of computing system 100, but can be implemented, for example, as a separate computing system.

[0026] Memory 126 can store any of the data, programs, or other software elements described herein, such as model creator 154, controller model 156, code generator 158, configuration specification 160, control app 162, among others. Memory 126 also contains an operating system 152 which can provide a graphical user interface (GUI) that can be utilized by a user to create or modify some of the software elements, as described herein.

[0027] FIG. 2 shows a process flow 200 for automatically generating a control app that can be readily deployed on a target device 140 having an open real-time platform. Consistent with disclosed embodiments, the target device 140 may comprise an edge computing device, such as a controller for controlling a physical device of the automation system (e.g., a robot, an AGV, etc.). In other embodiments, the target device 140 may comprise a simulation computer that simulates a real-time controller for testing or tuning the generated control app. The open real-time platform is enabled by an inter-app communication layer 206 and a real-time execution service 208 on the target device 140. The process flow 200 comprises a set of operations that may be implemented, for example, by the computing system 100 which may include an engineering system for industrial automation. Those of skill in the art will recognize that, unless specifically indicated or required by the sequence of operations, certain steps in the described process may be omitted, performed concurrently or sequentially, or performed in a different order.

[0028] According to disclosed embodiments, the inter-app communication layer 206 comprises, at its lowest layer, a platform-independent data-centric middleware enabling standardized data communication across multiple processes. In one embodiment, the middleware may use the Data Distribution Service (DDS) standard to implement real-time publisher/subscriber-based communication between processes. As such, the data-centric middleware is agnostic to the processes or apps running on the target device 140 and simply establishes data flow based on matching of data between processes or apps that consume data and those that provide data.

[0029] A task-specific domain model is built on top of the underlying middleware, which can be used to abstract the middleware to a specified control task. The domain model may be implemented as a library containing a semantical description of how different processes can understand each other during runtime to execute the specified control task. For example, the domain model may define topics (e.g., “speed”, “temperature”, etc.) for the data-centric middleware and further define the data used by each process executed in the control loop using tags that map on to these topics. A tag may specify, for example, a tag name (e.g., “sensor_in”, “motor_out”), a data type (e.g., integer, double, etc.), a dataflow direction (“consume” or “provide”), a quality of service (e.g., reliable, best effort, redundant, etc.), among others. The domain model is used to create one or more inter-app communication APIs which can ensure that whatever is presented to the middleware by a process or app conforms with the domain model. The inter-app communication APIs are standardized and can be used by third-party apps to fully integrate and utilize the middleware to establish data communication between processes or apps running on the target device 140.

[0030] The real-time execution service 208 is an open-platform service which defines real-time behavior, monitors it, and manages system resources appropriately between real-time processes. To that end, the real-time execution service 208 may include a number of services to ensure that determinism can be achieved when executing control loops on the target device 140. These services may include a scheduling service 306, a centralized clock service 308, and a monitoring service 310, among others (see FIG. 3). [0031] The real-time execution service 208 may provide scheduling service APIs across multiple processes to access the scheduling service for scheduling each process (typically a function call for a cyclic loop) based on one or more specified real-time requirements. The real-time requirements may include, for example, a cycle time, a real-time priority, a CPU core affinity, among others. The scheduling service can guarantee that each process always gets the required CPU slice to execute a task at a defined interval with a defined real-time priority on a designated CPU core on the target device 140.

[0032] The real-time execution service 208 may also provide clock service APIs across multiple processes to access the centralized clock service to coordinate the execution of the control loops. This can be critical for an open system so that different processes can keep in sync with each other using such a service. In this way, even when the functions are executed in separate processes, they can still form a single correct control loop in real-time.

[0033] The real-time execution service 208 may also provide monitoring service APIs for monitoring a real-time performance in the execution of the control loops. The real-time performance may be indicative, for example, of a deadline violation and/or jitter. A deadline violation may be said to occur if the runtime of a control loop iteration exceeds the specified cycle time. Deadline violations may be expressed, for example, as the number of violations per minute (or any other defined interval). On the other hand itter is measured as the amount of error in the timing of a process over subsequent iterations of a control loop. In this way, a user may be informed about the overall performance and make adjustments (e.g., modify the controller model to simplify a complex algorithm, increase the cycle time, etc.) if determinism cannot be met for certain a control loop.

[0034] The APIs provided by the inter-app communication layer 206 and the real-time execution service 208 are enablers for the automatic code generation process described below.

[0035] According to the illustrated process flow 200, a controller model 156 is created using a model creator 154. The controller model 156 comprises a model representation of a controller in a physical system for executing a specified control task. The model creator 154 can include any commercially available tool or programing framework that allows a user to effectively model a physical system including the controller. Preferably, the model creator 154 allows a user to use graphical block diagramming tools to describe the physical system. Non-limiting examples of a model creator 154 suitable for the present purpose include Matlab Simulink® developed by MathWorks Corporation, LabView® developed by National Instruments, Modelica® developed by Modelica Projects Association, among others.

[0036] An illustrative and non-limiting example of a controller for a physical device is shown in FIG. 4. The physical device includes, in this example, an automated guided vehicle (AGV) 400, which is controllable by an embedded controller 402. The controller 402 includes, in this example, a PCbased computing device operating on a general-purpose OS, such as Linux with PREEMPT-RT patch. The control task to be executed by the controller 402 is to ensure that the AGV 400 follows a line 404 in the form a circular black strip on the floor. The AGV 400 has an array of four line sensors 406a-d (not visible) pointing to the floor. Each line sensor can output a binary signal indicative of the presence or absence of the line 400 directly below the respective sensor. The line sensors 406a-d may comprise, for example, infra-red sensors. Based on the position of each line sensor in the array, the sensor signals may be designated as “left”, “center-left”, “center-right” and “right” (see FIG. 5). The AGV 400 is movable via a pair of continuous tracks, namely a left track 408a and a right track 408b, actuated by respective motors. To execute a control loop, the controller 402 has to read sensor data from the line sensors 406a-d, process the sensor data, and output a control action (e.g., moving the AGV left or right by increasing the speed of one track relative to the other), which has to be communicated to the motors actuating the respective tracks 408a, 408b. The controller 402 may also implement control actions based on an input received from a remote terminal 410, via an input device, such as a keyboard. Such control actions may include, for example, starting or stopping the AGV, or controlling the overall speed of the AGV.

[0037] FIG. 5 illustrates a corresponding block diagram of a model representation 500 of the physical system shown in FIG. 4, created using Simulink®. The shown block 502 is a high-level (expandable) representation of the controller, which is implemented in this example as a proportional- integral-derivative (PID) controller. The input 504 to the controller 502 is “Line-sensor”, which specifies the binary output of the four line sensors described above. For each control loop, controller 502 reads the input 504 and processes it using a PID control algorithm to compute an output 506, which specifies the track speeds (“Track-right”, “Track-left”) of the left and right tracks of the AGV described above.

[0038] Turning back to FIG. 2, the code generator 158 transforms the controller model 156 into controller code 202. Many modeling frameworks have a built-in code generation mechanism that can be used to convert a model representation of a controller into source code (e.g., in C/C++). For example, in Simulink®, this mechanism is known as target language compiler (TLC). Continuing with the example illustrated herein, the TLC may be capable of converting the controller model 502 into source code for implementing PID control (i.e., controller code 202). However, the source code generated by such a mechanism cannot be deployed on an open hardware (e.g., PC-based controller) to execute real-time control loops without extensive integration.

[0039] The code generator 158 according to disclosed embodiments additionally reads a configuration specification 160, which includes data definition mapped to an input and output in the model representation of the controller 156/502 and execution definition specifying a real-time requirement for execution on the target device 140. In embodiments, the configuration specification 160 may comprise one or more artifacts (e.g., files) created in a human readable and machine parseable format, such as YAML, JSON, or XML, which can provide the user a complete view of the system. The artifact(s) may be created based on a user input, which may include directly using a text editor to create the artifact(s) and/or generating the artifact(s) automatically based on inputs received via dialog boxes provided by the GUI, among others.

[0040] According to disclosed embodiments, the data definition in the configuration specification 160 is based on assignment of tags to input-output data in the model representation of the controller 156/502. The assigned tags, in turn, map on to topics in the data-centric middleware abstracted by the domain model to create the one or more inter-app communication APIs, as described above. For example, each tag may be defined by a number of fields including a data type, a dataflow direction, a quality of service (QoS), among others.

[0041] The following is an example of a data definition in YAML format, for the illustrative and non-limiting example shown in FIGS. 4 and 5. As shown, tags in the data definition match the input (e.g., “Line- sensor”) and output (e.g., “Track-left”, “Track-right”) of the modelled controller 502. api vers ion : ' vO .1 ' kind: 'configuration' applns tance : meta information name: 'MatlabFollowLine ' for control app domainld : 0 systemName: 'AGV1' description: 'controls AGV to follow tags :

- name : ' trackspeed_out ' connect: 'trackspeed' direction: 'provider' dataType: 'TrackSpeed' exportAs :

- MatlabTagName : ' Process_value ' memberDataType : ' double ' memberName : ' speedPercent '

- name : ' motor_out ' controller model connect: 'motor' output data direction: 'provider' definition

#qos: 'bestEffort' dataType: 'Motor' exportAs :

- MatlabTagName : ' Track_left ' memberDataType: 'inf memberName: 'leftSpeed'

- MatlabTagName : ' Track_righf memberDataType: 'inf memberName: 'rightSpeed'

- name : ' line-in ' connect : ' line '

#qos: 'bestEffort' direction: 'consumer' controller model dataType: 'VariantTag' input data exportAs : definition

- MatlabTagName : ' Line_sensor ' memberDataType: 'inf memberName : ' value ' unionMemberName : ' i ' appConf ig :

- name : ' name ' type : ' String ' value ' Matlab '

- name : ' domainld ' type : ' Integer ' value : 0

- name : ' sys temName ' type : ' String ' value : ' AGV1 '

[0042] According to disclosed embodiments, the execution definition in the configuration specification 160 may specify, as real-time requirements, a cycle time, a real-time priority and a CPU core affinity, among others. The code generator 158 may translate the execution definition into interface code 204 with function calls to the one or more APIs provided by the real-time execution service 208. Similar to the data definition, the execution definition may comprise an artifact (e.g., a file) created in a human readable and machine parse-able format, such as YAML, JSON, or XML, based on a user-input (e.g., using text editors, dialog boxes, etc.).

[0043] The code generator 158 is programmed to parse the configuration specification 160 to generate interface code 204, which is configured to interface with the inter-app communication layer 206 based on the data definition and to interface with the real-time execution service 208 based on the execution definition. In particular, the code generator 158 may parse the configuration specification file(s), for example, by looking up tags, real-time requirements, etc., to match the interface code 204 to the APIs provided by the inter-app communication layer 206 and the real-time execution service 208. Thereby, the data provided and consumed in the control loops can conform to the domain model of the inter-app communication layer 206 and the execution steps can be carried out in sync with the real-time execution service 208.

[0044] The code generator 158 then links the interface code 204 and the controller code 202 to generate source code for the control app 162. The control app 162 may be deployed, for example, as a Cmake project, or a container, or any other stand-alone project, which can be compiled for the target device 140 to generate an executable 210. The automatic generation and linking of the interface code 204 with the controller code 202 can thus take care of the integration of advanced numeric computation engines into an open ecosystem, such that the generated control app 162 can interact with the inter-app communication layer 206 and the real-time execution service 208 to execute control loops.

[0045] FIG. 3 illustrates an architecture of an open real-time platform in the target device 140 wherein the control app 162 may be deployed. As described herein, the open real-time platform is realized by the inter-app communication layer 206, which provides inter-app communication APIs 302, and the real-time execution service 208, which provides a number of execution service APIs 304. The execution service APIs 304 include scheduling service APIs providing access to a scheduling service 306, clock service APIs providing access to a centralized clock service 308 and monitoring service APIs providing access to a monitoring service 310. The APIs 302, 304 are usable across multiple processes or apps running on the target device 140. These include the control app 162 and a number of I/O processes 312 that cooperate in executing a control loop. For executing a control loop, the control app 162 can interact with the inter-app communication layer 206 and the real-time execution service 208 via the respective APIs 302, 304 using the interface code 204.

[0046] For example, the interface code 204 is configured to allow the control app 162 to use the inter-app communication APIs to provide data to and consume data from the inter-app communication middleware. The interface code 204 is also configured to allow the control app 162 to use the scheduling service APIs to access the scheduling service 306 for scheduling a control loop based on specified real-time requirements, such as cycle time, real-time priority and CPU core affinity. The interface code 204 is also configured to allow the control app 162 to use the clock service APIs for accessing the centralized clock service to enable the real-time execution service 208 to coordinate the execution of each control loop, as described below. Furthermore, the interface code 204 may be configured to allow the control app 162 to use the monitoring service APIs to access the monitoring service for monitoring deadline violations, jitters, or other real-time performance indicators, allowing adjustments to be made in the control app (e.g., modify the controller model to simplify a complex algorithm, increase the cycle time, etc.) if determinism cannot be met for certain a control loop.

[0047] The data-centric middleware in the inter-app communication layer 206 ensures that, at each control loop, a communication link can be established between processes if a first process publishes data that belongs to a topic which is subscribed to by a second process, has the same data type and a compatible QoS as requested by the second process, and also contains the key as requested by the second process. A key can be an identifier, similar to a primary key in a database, which may be used to establish instances in the physical system. If the above condition is met, a data flow is established from the first process (provider) to the second process (consumer).

[0048] The real-time execution service 208 may instantiate control loops at defined intervals based on the specified cycle time using the centralized clock service 308. Within each loop, the real-time execution service 208 may trigger multiple processes in a sequence. The I/O processes 312 may include at least a first I/O process 312a configured to grab input signals 314, which may include sensor signals, and a second I/O process 312b configured to generate output signals 316, which may include actuator signals.

[0049] The real-time execution service 208 may coordinate each control loop by first triggering the first I/O process 312a. The first I/O process 312a may then provide state data to the middleware in the inter-app communication layer 206 based on the received input/sensor signals 314. Next, the control app 162 may be triggered by the real-time execution service 208. The control app 162 may consume, using the interface code 204, state data from the middleware in the inter-app communication layer 206 which was provided by the first I/O process 312a, based on satisfaction of the conditions for data flow as described above. The control app 162 may then process, using the controller code 202, the state data to determine a control action. The control app 162 may then provide, using the interface code 204, action data to the middleware in the inter-app communication layer 206 based on the determined control action. Next, the real-time execution service 208 may trigger the second I/O process 312b. The second I/O process 312b may consume the action data from the middleware in the inter-app communication layer 206, based on satisfaction of the conditions for data flow as described above, to generate output/actuator signals 316.

[0050] In one embodiment, as exemplified in FIG. 4, the target device 140 may include a controller used to control physical device. In this case, the input/sensor signals 314 can include signals received from a sensor and the generated output/actuator signals can include signals provided to an actuator for controlling the physical device. In an alternate scenario, the controller hardware may be used for controlling a simulation model of a physical device including sensors and actuators (hardware-in-the- loop simulation). In this case the input/sensor signals 314 can include signals from a simulation model of the sensor and the generated output/actuator signals 316 can include signals provided to a simulation model of the actuator. A hardware-in-the-loop simulation may be carried out, for example, for testing or tuning the control app 162, for example, by adjusting the cycle time and/or parameters of the control algorithm (e.g., such as proportional, integral, derivative, filter coefficient, etc.). In other embodiments, the target device 140 may include a simulation computer implementing a simulation model of a real-time controller, for testing or tuning the control app 162 (e.g., as described above) before deployment on a controller hardware.

[0051] FIG. 6 illustrates an example of inter-app communication based on the example shown in FIGS. 4 and 5. Here, a first I/O process is implemented by an app 602 (“LineSensor AGVl”) that grabs signals from the line sensors 406a-d, a second I/O process is implemented by an app 604 (“TrackDriver AGVl”) that generates signals for the motors for driving the left and right tracks 408a, 408b of the AGV 400, and a third I/O process is implemented by an app 606 (“Keyboard AGVl”) that generates signals for the motors based on an input received via a keyboard in the remote terminal 410. The app 608 (“MatlabFollowLine”) is a control app generated using the above-disclosed code generator based on a Matlab Simulink® model of the controller. The boxes 610, 612, 614, 616 indicate topics of the inter-app communication middleware defined by the domain model.

[0052] When a control loop is instantiated, the app 602 publishes line sensor data, with tag name “line out”, to the middleware, which belongs to the topic 610 (“line”). The control app 608, which subscribes to the topic 610, consumes the line sensor data, with tag name “line in”, from the middleware. The control app 608 then publishes action data to the middleware, with tag names “motor out” and “trackspeed ouf ’, which belong to the topics 612 (“motor”) and 614 (“trackspeed”) respectively. The app 604, which subscribes to the topics 612, 614 consumes the action data from the middleware, with tag names “motor in” and “trackspeed in”, to generate corresponding signals for the motor for driving the tracks. The app 606 may also publish action data, with tag names “trackspeed” and “agvstartstop”, to the middleware, based on an input received via the keyboard. The action data published by the app 606 belong the topics 614 (“trackspeed”) and 616 (“agvstartstop”), which are also subscribed by the app 604. The app 604 may consume such action data, with tag names “trackspeed in” and “agvstartstop in”, to generate signals for the motor.

[0053] The embodiments of the present disclosure may be implemented with any combination of hardware and software. In addition, the embodiments of the present disclosure may be included in an article of manufacture (e.g., one or more computer program products) having, for example, a non- transitory computer-readable storage medium. The computer readable storage medium has embodied therein, for instance, computer readable program instructions for providing and facilitating the mechanisms of the embodiments of the present disclosure. The article of manufacture can be included as part of a computer system or sold separately.

[0054] The computer readable storage medium can include a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network.

[0055] Although an exemplary embodiment of the present disclosure has been described in detail, those skilled in the art will understand that various changes, substitutions, variations, and improvements disclosed herein may be made without departing from the spirit and scope of the disclosure in its broadest form.

Claims

CLAIMS What is claimed is:

1. A method for implementing a real-time controller for an automation system, the method performed by a computing system and comprising: starting a code generator to transform a model representation of a controller into controller code to be executed on a target device, reading a configuration specification by the code generator, the configuration specification including data definition mapped to an input and output in the model representation of the controller and execution definition specifying a real-time requirement for execution on the target device, parsing the configuration specification by the code generator to generate interface code configured to use an API provided by an inter-app communication layer in the target device based on the data definition, and to use an API provided by a real-time execution service running on the target device based on the execution definition, and linking the interface code with the controller code by the code generator to generate a control app for deployment on the target device, whereby the deployed control app is configured to interact, using the interface code, with the inter-app communication layer and the real-time execution service on the target device to execute control loops.

2. The method according to claim 1 , wherein the inter-app communication layer comprises a platform-independent data- centric middleware and a task-specific domain model built on top of the middleware for abstracting the middleware to a specified control task, wherein the domain model is used to create one or more inter-app communication APIs usable by the interface code to access the inter-app communication layer to execute the control loops.

3. The method according to claim 2, wherein the data definition in the configuration specification used for generating the interface code is based on assignment of tags to input-output data in the model representation of the controller, wherein the tags map on to topics in the data-centric middleware abstracted by the domain model to create the one or more inter-app communication APIs.

4. The method according to claim 3, wherein each tag is defined by a number of fields including a data type, a dataflow direction and a quality of service (QoS).

5. The method according to any of claims 1 to 4, wherein the interface code, generated based on the execution definition, is configured to allow the control app to use one or more scheduling service APIs provided by the real-time execution service to access a scheduling service for scheduling the control loops on the target device.

6. The method according to any of claims 1 to 5, wherein the real-time requirement specified in the execution definition includes a cycle time, a real-time priority and a CPU core affinity.

7. The method according to any of claims 1 to 6, wherein the configuration specification comprises one or more artifacts created in a human readable and machine parseable format based on a user-input.

8. The method according to any of claims 1 to 7, wherein the real-time execution service is configured to provide multiple processes running on the target device with access to a centralized clock service via one or more clock service APIs, to coordinate the execution of the control loops, and wherein the interface code is configured to allow the control app to use the one or more clock service APIs for accessing the centralized clock service for the coordination of each control loop.

9. The method according to claim 8, wherein, for each control loop, the control app is configured to carry out: consuming, using the interface code, state data from the inter-app communication layer, the state data for each control loop being provided to the inter-app communication layer by a first I/O process running on the target device based on received sensor signals, processing, using the controller code, the state data to determine a control action, and providing, using the interface code, action data to the inter-app communication layer based on the determined control action, the action data for each control loop being consumed from the inter-app communication layer by a second I/O process running on the target device to generate actuator signals.

10. The method according to any of claims 1 to 9, wherein the real-time execution service provides one or more monitoring service APIs usable by the control app for monitoring a real-time performance, indicative of a deadline violation and/or a jitter in the execution of the control loops.

11. The method according to any of claims 1 to 10, wherein the target device operates on a general-purpose operating system (GPOS).

12. A non-transitory computer-readable storage medium encoded with instructions that, when processed by a computing system, configure the computing system to perform the method according to any of claims 1 to 11.

13. A computing system comprising: one or more processors, a non-transitory memory storing instructions executable by the one or more processors to perform a method according to any of claims 1 to 11.

14. An automation system comprising: a controller for controlling a physical device, the controller including a computing device having an open real-time platform that comprises: an inter-app communication layer providing one or more APIs usable by multiple processes running on the controller for standardized communication between processes running on the controller, and a real-time execution service providing one or more APIs usable by the multiple processes to coordinate execution of control loops based on a real-time requirement, and an engineering system comprising one or more processors, and a non-transitory memory storing instructions executable by the one or more processors to generate a control app by a method according to any of claims 1 to 11 for deployment on the controller, whereby the deployed control app is configured to utilize the APIs provided by the inter-app communication layer and the real-time execution service to execute control loops on the controller.