- \n
- Part 1 – Designing a next-gen embedded HMI<\/a><\/li>\n
- Part 2 – Implementing a next-gen HMI in SCADE Display<\/a><\/li>\n
- Part 3 – Powering a next-gen HMI with SCADE Suite<\/a><\/li>\n
- Part 4 – Integrating a next-gen HMI onto a hardware target<\/a><\/li>\n<\/ul>\n
\nIntroduction<\/h3>\n
This article presents an overview of the integration of a SCADE-developed HMI for an industrial steam boiler onto a realistic hardware target.<\/p>\n
The steam boiler is like the one you’d find in a nuclear power plant. It uses a heat source (e.g. nuclear fuel) to produce steam. It is controlled by a reactive control loop that balances sensor readings (temperature, steam pressure, water level) within acceptable parameters by using actuators (water injection valves).<\/p>\n
In our previous article, we used SCADE Display to implement the HMI panel and SCADE Suite for the panel behavior. We will now use the SCADE certified code generators to generate C code from our models. We’ll then embed it onto a hardware target.<\/p>\n
As a reminder, here is what our graphical panel looks like:<\/p>\n
\n
![](\"https:\/\/innovationspace.ansys.com\/knowledge\/wp-content\/uploads\/sites\/4\/2024\/07\/scade-016-hmi-overview.jpg\")
\n Overview of our HMI panel in rescue mode<\/em>\n<\/p>\nHardware target <\/h3>\n
In the world of safety-critical applications, application code usually runs on specialized technological platforms. Hardware tends to be ruggedized to resist adverse conditions: vibration, wide temperature ranges or even harsh radiation. CPUs may use reduced instruction set (RISC) architectures instead of the ubiquitous x86 architecture found in desktops and laptops. Operating systems tend to be real-time (RTOS), as the timely computation of results matters as much as the results themselves.<\/p>\n
In our case, we will be using two distinct environments:<\/p>\n
- \n
- Our development machine is a laptop with an Intel Core-i7 x86-64 CPU and an RTX A2000 GPU, running Windows 11.<\/li>\n
- Our Smart Boiler hardware is an i.MX 8 board with an ARM Cortex-A53 CPU and a GC7000 GPU, running a Linux OS. We will be using an external display screen connected to the board via an HDMI connector.<\/li>\n<\/ul>\n
Code generation in SCADE<\/h3>\n
SCADE relies on qualified code generators to generate safe, embeddable, platform-independent C code. Let’s unpack this:<\/p>\n
- \n
- The code is safe<\/strong> because the Scade language avoids many categories of bugs by construction (e.g. uninitialized memory access), and because our KCG code generator is qualified to the highest levels of safety with key safety standards (such as DO-178C, ISO26262, EN50128 or IEC 61508).<\/li>\n
- The code is embeddable<\/strong> because it’s ready to be compiled and executed on various hardware platforms without modification. For SCADE Display graphical panels, the target just needs to support some flavor of OpenGL.<\/li>\n
- The code is platform-independent<\/strong> because no system calls are made in it. Aside from drawing calls for graphical panel code, there are no I\/Os, no filesystem interaction, no dynamic memory allocation, no networking. Interaction with the outside world (e.g. through input devices) is managed by reading\/writing pre-allocated structures.<\/li>\n<\/ul>\n
Code Integration<\/h4>\n
Running a program built with SCADE Display & SCADE Suite requires a small integration layer that performs the program’s initialization phase. This code performs the following activities:<\/p>\n
- \n
- Allocate a known, static amount of memory for the program<\/li>\n
- Create and initialize structures that will be used by the generated code<\/li>\n
- Initialize display drivers<\/li>\n
- Initialize input devices<\/li>\n
- Call the model’s entry-point operator.<\/li>\n<\/ul>\n
For real-time operating systems that use a task scheduler, integration code must create and launch a task to run the SCADE model’s main operator.<\/p>\n
SCADE Suite includes wrappers for Windows host and a selection of widely-used embedded targets. These wrappers automatically generate the integration code as part of the push-button build from the SCADE Display IDE.<\/p>\n
Graphics drivers<\/h4>\n
SCADE Display supports many flavors of OpenGL (vanilla, ES, SC) in different versions. Each one has a slightly different API shape: the embedded and safety-critical flavors offer less functions. To accommodate this, SCADE relies on a middleware library called OGLX.<\/p>\n
In practice, this is the flow of drawing calls in a SCADE Display program:<\/p>\n
\n
![](\"https:\/\/innovationspace.ansys.com\/knowledge\/wp-content\/uploads\/sites\/4\/2024\/07\/scade-016-call-stack.svg\")
\n Drawing call flow for a SCADE Display program<\/em>\n<\/p>\nSGL is a higher-level interface provided for graphical calls by OGLX. They allow the SCADE program to speak a “common language” that can then be adapted by the library into calls in the corresponding OpenGL flavor.<\/p>\n
OGLX is written in C. Its source code is certifiable to the highest levels of safety with key safety standards. Sources are delivered with SCADE and must be configured, compiled and linked for the target hardware. This is typically achieved from a Windows host computer with correct parameters for cross-compilation to the desired target.<\/p>\n
Compilation pipeline<\/h4>\n
Overall, the generation and compilation pipeline looks like this:<\/p>\n
\n
![](\"https:\/\/innovationspace.ansys.com\/knowledge\/wp-content\/uploads\/sites\/4\/2024\/07\/scade-016-integration-overview.svg\")
\n Overall generation pipeline for a SCADE Suite \/ SCADE Display program<\/em>\n<\/p>\nGenerating for Windows host<\/h4>\n
While developing and testing a SCADE application, engineers need to run it frequently. Since the SCADE IDE runs on Windows, generating code and building it for a Windows host target is a common use case. It is therefore supported as a “push button” activity.<\/p>\n
In our Smart Boiler example, the SCADE Display model includes the SCADE Suite model as a library. So, the whole process is triggered from a SCADE Display Generator Configuration.<\/p>\n
\n
![](\"https:\/\/innovationspace.ansys.com\/knowledge\/wp-content\/uploads\/sites\/4\/2024\/07\/scade-016-display-gen-conf-windows.png\")
\n Windows executable generation configuration in SCADE Display<\/em>\n<\/p>\nThis configuration triggers the whole process: code generation using KCG Display for the Display model and KCG for the Suite model, generation of integration code for a Windows host, compilation and linking of the program for a Windows host, and launch of the finalized program in a new window.<\/p>\n
Note: to save time in this case, the OGLX library is precompiled.<\/p>\n
In addition to the Windows generation configuration, you can see above another one called Simulation. This simulation launches the program with debugging enabled. An integrated window allows to run the program at various speeds, pause it, interact with the HMI, and watch underlying variables.<\/p>\n
\n
![](\"https:\/\/innovationspace.ansys.com\/knowledge\/wp-content\/uploads\/sites\/4\/2024\/07\/scade-016-display-co-simulation.png\")
\n Interactive co-simulation window<\/em>\n<\/p>\nGenerating for Linux iMX 8<\/h4>\n
Now, let’s look at generating the program for its intended embedded target. For our Smart Boiler, we have chosen a widely-used hardware platform:<\/p>\n
- \n
- Hardware platform: NXP i.MX 8QuadMax MEK <\/li>\n
- Graphics: GC7000 – Vivante<\/li>\n
- CPU: ARM Cortex-A53<\/li>\n
- OS: Yocto Linux 4.14.78<\/li>\n
- Graphics Driver: OpenGL SC 2.0 – CoreAVI <\/li>\n
- Display: external HDMI screen<\/li>\n<\/ul>\n
We start by launching the Code generation configuration from SCADE Display. This generates C code for the SCADE Display and SCADE Suite models.<\/p>\n
OGLX configuration for Linux iMX8<\/h4>\n
Next, we retrieve the OGLX source code and ready it for cross-compilation via the included
oglx_port.h<\/code> file. While the file can be modified to accommodate the desired target, in our case, we can simply rely on one of the pre-included macros to control common target restrictions and build features.<\/p>\nOur target has no specific restriction, so we don’t need to define any of the following macros:<\/p>\n
<\/p>\n
\n<\/span>\/*****************************************************************************************************************<\/span>\r\n Specific OGLX porting macro definitions<\/span>\r\n\r\n Following macros can be defined if the user environment does not provide a feature<\/span>\r\n OGLX_NO_VERTEX_ARRAY | Vertex arrays are not provided by the used OpenGL driver<\/span>\r\n OGLX_NO_GLCLIPPLANE | Clip planes are not provided by the used OpenGL driver<\/span>\r\n OGLX_NO_64_BITS | 64 bits integers are not provided by the compiler environment<\/span>\r\n OGLX_NO_FTOL2 | Cast between float and 64 bits integers is not provided by the compiler environment<\/span>\r\n Following macros can be undefined if the user environment does not provide a feature<\/span>\r\n OGLX_FBO | Static mechanism uses frame buffer objects (To undefine if FBOs are not provided)<\/span>\r\n OGLX_DISPLAY_LISTS | Static mechanism uses display lists (To undefine if display lists are not provided)<\/span>\r\n\r\n*****************************************************************************************************************\/<\/span>\r\n<\/pre>\n<\/div>\nWe want to use an OpenGL SC2 driver, so we define the
SC2_DEV_ENV<\/code> macro: <\/p>\n<\/p>\n
\n<\/span>#elif defined(SC2_DEV_ENV)<\/span>\r\n#include<\/span> <\/span><GLSC2\/glsc2.h><\/span>\r\n#define OGLX_FBO<\/span>\r\n#define OGLX_MASK_FFFF 0xFFFF<\/span>\r\n<\/pre>\n<\/div>\nWith this single change, we can pre-compile OGLX as a static library (
liboglx.a<\/code>).<\/p>\nMain function for Linux iMX8<\/h4>\n
We now need to write a
main.c<\/code> file to tie everything together.<\/p>\nOur main function’s job is to:<\/p>\n
- \n
- Initialize the display in the correct resolution<\/li>\n
- Initialize OGLX and the underlying display driver<\/li>\n
- Start an infinite rendering loop to:\n
- \n
- Render the next frame into a hidden graphical buffer<\/li>\n
- Swap the hidden and screen buffers to display our new frame<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
We also elect to start our main function in its own thread, but we will leave details out for simplicity’s sake. Here’s what the code for our main function looks like:<\/p>\n
<\/p>\n
\n<\/span>void<\/span> <\/span>sampleApp1Thread<\/span>(void<\/span> <\/span>*<\/span>pHead)\r\n{\r\n <\/span>\/* Initialize required structures *\/<\/span>\r\n <\/span>uint32 <\/span>threadId <\/span>=<\/span> <\/span>*<\/span>((uint32 <\/span>*<\/span>)pHead);\r\n <\/span>EGLDisplay <\/span>*<\/span>dpy <\/span>=<\/span> <\/span>NULL<\/span>;\r\n <\/span>EGLContext <\/span>*<\/span>ctx <\/span>=<\/span> <\/span>NULL<\/span>;\r\n <\/span>EGLConfig <\/span>*<\/span>cfg <\/span>=<\/span> <\/span>NULL<\/span>;\r\n <\/span>EGLSurface <\/span>*<\/span>sfc <\/span>=<\/span> <\/span>NULL<\/span>;\r\n <\/span>EGLNativeDisplayType <\/span>*<\/span>dpyId <\/span>=<\/span> <\/span>NULL<\/span>;\r\n <\/span>EGLBoolean <\/span>errorStatus <\/span>=<\/span> <\/span>EGL_TRUE;\r\n <\/span>GLuint <\/span>shaderProgram <\/span>=<\/span> <\/span>0<\/span>;\r\n <\/span>GLint <\/span>aVertex <\/span>=<\/span> <\/span>0<\/span>;\r\n <\/span>GLint <\/span>aVertexColor <\/span>=<\/span> <\/span>0<\/span>;\r\n <\/span>GLint <\/span>aTexCoord <\/span>=<\/span> <\/span>0<\/span>;\r\n <\/span>GLint <\/span>uTexUnit <\/span>=<\/span> <\/span>0<\/span>;\r\n <\/span>GLint <\/span>uRotation <\/span>=<\/span> <\/span>0<\/span>;\r\n <\/span>\r\n <\/span>dpy <\/span>=<\/span> <\/span>&<\/span>f_dpy;\r\n <\/span>ctx <\/span>=<\/span> <\/span>&<\/span>f_eglContext;\r\n <\/span>cfg <\/span>=<\/span> <\/span>&<\/span>f_config;\r\n <\/span>sfc <\/span>=<\/span> <\/span>&<\/span>f_surface;\r\n\r\n <\/span>\/* Initialize a display using EGL *\/<\/span>\r\n <\/span>errorStatus <\/span>=<\/span> <\/span>egl_init(dpy, <\/span>ctx, <\/span>cfg, <\/span>sfc);\r\n <\/span>if<\/span> <\/span>(EGL_FALSE <\/span>==<\/span> <\/span>errorStatus)\r\n <\/span>{\r\n <\/span>printf("[SampleApp1:Thread%d] Display failed creation. Aborting\\n"<\/span>, <\/span>threadId);\r\n <\/span>return<\/span>;\r\n <\/span>}\r\n\r\n <\/span>\/* Initialize OGLX *\/<\/span>\r\n <\/span>oglx_init();\r\n <\/span>init_scene();\r\n\r\n <\/span>\/* Main loop proper *\/<\/span>\r\n <\/span>while<\/span> <\/span>(TRUE)\r\n <\/span>{\r\n <\/span>\/* Render the next frame into a buffer *\/<\/span>\r\n <\/span>display_callback();\r\n\r\n <\/span>\/* Swap buffers to display the next frame *\/<\/span>\r\n <\/span>if<\/span> <\/span>(EGL_TRUE <\/span>!=<\/span> <\/span>eglSwapBuffers(*<\/span>dpy, <\/span>*<\/span>sfc))\r\n <\/span>{\r\n <\/span>printf("[SampleApp1] ERROR: eglSwapBuffers() unexpected error rendering to display %d"<\/span>, <\/span>*<\/span>((uint32 <\/span>*<\/span>)dpy));\r\n <\/span>}\r\n <\/span>}\r\n}\r\n<\/pre>\n<\/div>\nNow, let’s dive further into interesting details of what happens under the hood.<\/p>\n
Create a display using EGL<\/h5>\n
EGL is a native platform interface that connects the windowing systems to one of Khronos’ APIs, e.g. OpenGL SC 2.<\/p>\n
Before getting to OpenGL, we first need to set it up. We will create an EGL render context using OpenGL SC as the client API connecting to the “display”. The term display may sound a bit odd at first if you’re used to Windows. It may be more familiar if you’re coming from Linux.<\/p>\n
Let’s look at some key things happening inside of our
egl_init(...)<\/code> function call above.<\/p>\nFirst, we get a device context from our window and connect it to the EGL display:<\/p>\n
<\/p>\n
\n<\/span> <\/span>\/* Obtain an EGL Display *\/<\/span>\r\n <\/span>if<\/span> <\/span>(EGL_TRUE <\/span>==<\/span> <\/span>errorStatus)\r\n <\/span>{\r\n
- The code is embeddable<\/strong> because it’s ready to be compiled and executed on various hardware platforms without modification. For SCADE Display graphical panels, the target just needs to support some flavor of OpenGL.<\/li>\n
- The code is safe<\/strong> because the Scade language avoids many categories of bugs by construction (e.g. uninitialized memory access), and because our KCG code generator is qualified to the highest levels of safety with key safety standards (such as DO-178C, ISO26262, EN50128 or IEC 61508).<\/li>\n
- Part 2 – Implementing a next-gen HMI in SCADE Display<\/a><\/li>\n