 Hello everybody, welcome to this webinar. I am Frédéric from ISIT and I am very pleased to be your host today. This webinar will deal about how to manage safety critical industrial development based on STM32 and it is a common webinar with ST, micro-electronic, ambilit office and ISIT. Before to start the webinar, I would like to remind you some information about this session of webinar. So first this session will be recorded and video will be available for all the attendees after the webinar. Secondly, all the attendees except the presenter of course will be muted during the webinar including the Q&A session we will have at the end. But at any time, be free to interact with us and to ask your question using the question panel you can find on the control panel of the Q2 webinar platform. Regarding our speakers today we have three amazing speakers that have done a really great job to prepare for you interesting presentations. So first of them is Loïc Chaucin, he is the senior marketing manager at ST Microelectronics. The second one is Christian Marca, he is a technical sales manager at the ambilit office and the last presentation will be done by Frank Montagnier, he is the CTO of ISIT. Regarding the goal and the agenda of this webinar, the goal of this webinar is to give you all the necessary information or information you think that could be very helpful for you for managing a safety critical industrial development and to ensure you to achieve all your requirements especially safety requirements. So the first presentation will be done by Loïc and will deal about the STM32 controller family and the self-test library included into this family. Then Marca will deal about flexible safety Airtoss platform and how such safety platform could be used as a confident foundation for building your software and your product on it. And then Frank will speak about communication and field bus and especially can open protocol with the can open safety stack. And he will tell you which type of service we can give to you in order to assist you during your development. So let's go and now it's the turn of Loïc, so good luck Loïc. Hello, I'm Loïc Chosa, ecosystem marketing at ST Microelectronics. STM32 is the ST Microelectronics 32 bit general purpose microcontroller and microprocessor family. It is well addressing the industrial applications. Many devices are proposed with an extended temperature range up to 125 degrees ambient and you can benefit from the 10 years longevity commitment from ST. Functional safety features like flash or RAM error code correction, watchdogs, PWM protections and many others enable use of STM32 in safety critical applications. A safety manual is available for each STM32 series. In addition, a security framework, STM32 trust helps you to protect your assets and meet the requirements of your security assurance level. A consistent and comprehensive software solution is offered with STM32 cube for all STM32, complemented by open STL Inox distribution for Cortex-A in STM32 MP1 microprocessors products. The STM32 family of microcontrollers and microprocessors offer many devices with high performance, real-time capabilities, digital signal processing, low power operation and connectivity. Among the latest introduced STM32 series, you can select STM32 H7 or STM32 MP1 if you need performance, STM32 G4 for motor control and digital power, STM32 G0 for entry cost, STM32 U5 for low power application with more security, STM32 WB and STM32 WL supporting RF protocols such as Bluetooth low energy, ZigBee, Lora or wireless Mbus. You may find all the links of STM32 ecosystem such as software, software tools or boards and STM32 solutions such as safety, motor control, graphics or artificial neural networks on the STM32 web page. Self-test libraries certified by TUVE Rheinland are available free of charge to speed up your safety certification. You can get functional safety documentation from ST such as FMEA or FMEDA. Please check STM32 functional safety web page for more information. Our partners, embedded office and EZIT propose additional software breaks and engineering services to help you implementing your STM32-based safety application. Here is an overview of the STM32 family with different CAN controller. CAN FD support was added in 2016 in addition to CAN 2.0 B on the STM32 H7 first and then deployed on almost all STM32 new families. Can open safety stack from EZIT as well as flexible safety air-tooth and safety add-on from embedded office are available on all these devices. Thank you Loïc for the exciting introduction to the safety investments of ST microelectronics into the STM32 microcontroller. My name is Christian Marca. My background is safety critical electronic systems mainly in aerospace applications respectively flight controls. I joined embedded office in 2019 as technical sales manager. It is a pleasure to present in this webinar the part of embedded office. Embedded office is a medium-sized company in the south of Germany. We develop and deal with embedded software mainly for safety critical applications such as automotive, aerospace, industrial, medical and railway for almost 20 years. We have partners and distributors worldwide and are proud to be an authorized safety partner of ST microelectronics. A close relationship we have with our distributor in France EZIT. Our solution pyramid represents a typical development life cycle in the safety critical environment. I will go into the details from the bottom to the top. In the first step we analyze together with a customer the project needs and provide a safety concept that fulfills the safety requirements and includes mitigation means. We propose selecting appropriate software components in step two such as our pre-certified flexible safety real-time operating system which comes with dedicated safety add-ons. Still we can also choose third-party products or open-source components such as micro micro COS plus middleware. In steps three we define the software platform which means we specify the architecture setup and integrate all selected software components. When needed we realize missing parts like a complex driver. Optionally in step four we can support the certification process by using pre-certified artifacts. This support means the provision and harmonization of safety manuals and the help during the certification process. To guarantee long-term safety management throughout your product's life cycle we add the final step with maintenance and support for the whole safety platform. This maintenance means active safety management including updates and bug fixes. We can provide the most suitable safety concept and safety platform for your project with this step-by-step approach. This life cycle is valid for all different safety standards and industrial markets. The most important step is at the beginning the safety concept but what shall we do for safety concept? This illustration demonstrates the activities with four iterations. It starts with a systems analysis. Here we identify the safety functions and analyze possible random faults. As you might know random faults are hardware faults occurring by age, heavy use or dirty environment. During the investigation we check the probability and the severity of each fault occurrence. In step two we identify matching overall system architectures with positive effects in avoiding the most critical random faults. The main topic in this phase is redundancy. So we think about which hardware redundancy best suits our safety goal. Step three is the phase where we calculate the failure rates and the diagnostic coverages of existing algorithms for detecting random faults. In this step we define which diagnostic measures we use to reach the required diagnostic coverage. You know that any fault we cannot avoid is a fault we must detect before a dangerous situation occurs. In the fourth step the overall safety concept is built up. This safety concept is a specification which defines the algorithms and timings of hardware self-tests to achieve your target safety capability. Well this is not done step by step. These activities influence each other leading us to a continuous improvement process we stop when we reach our safety goals. A parallel task to writing the safety concept is the capturing of the project needs. And what are the everyday project needs? Most of the time we all have already existing modules we want to use. I think on end of line production services, failure storage modules or maintenance components from previous or similar projects. Next is the essential part the reason why we start the development. This part includes the product specific algorithms and your product differentiating know-how is needed and builds up the core of the specific application. Your team should concentrate on this part. The complexity of communication and middleware features is constantly growing. Together with the rising expectations of our end customers we need to support these features. As we do not want to reinvent the wheel we use existing middleware and communication stacks. Many stacks for communication and middleware are available and we can select the best matching component for our project. We now have the situation in a safety project that we must combine existing software parts with off-the-shelf components and the safety application. This situation leads us to the separation of safe and non-safe software parts. The traditional way to separate the software parts into multiple microcontrollers is suitable for small projects only. In typical projects we achieve the separation on single microcontrollers with supporting hardware units integrated by the chip vendors who invest in safety capable microcontrollers like ST microelectronics. When interacting with the rest of the world our system needs to react to input events. We can handle this in a time-controlled way or event-based. Whichever software architecture you select the most critical factor for the safety point of view is the overall deterministic behavior. When working with communication many asynchronous events can raise a challenge. With a real-time kernel you achieve the deterministic reaction most effectively. Finally we want a future-proof software environment where we can add new features as efficiently as possible. These new features will come from our product manager and customers or IDs we have during the development phase. Extending your product for future variants is highly simplified when working with a real-time kernel. You typically capture all these system requirements in the variety of ways. With this collected set of system requirements the system specification describes the project's needs. At this point we have finished the bottom layer of our solution pyramid. Now we are well prepared for going forward to the next layer, selecting software components. Embedded office is an experienced partner in selecting software components for safety critical projects. The chosen component can be any middle-ware component such as TCP IP, a file system, USB or similar. Third-party software and open source components are extensively available. Core synchronization is an essential component necessary for transparent communication and synchronization of multiple cores. Encryption is another means which becomes more and more critical in the connected world. Appropriate encryption algorithms specialized for embedded systems support hardware security modules. For separation and deterministic real-time behavior, a real-time kernel provides optimum services. Several real-time operating systems are available on the market. Our product is the flexible real-time operating system which is pre-certified up to the highest safety levels for different standards. The flexible safety RTOS includes the so-called safety add-ons which monitor the program flow control, the time budget and the end-to-end protected communication. Finally, virtualization methods are possible. We provide a framework including a hypervisor to get a modular system architecture and the highest security. Our approach in this area is the outstanding solution of our partner Lynx Software Technologies. Let us examine a real-world example which I use to demonstrate what we need for our CAN Open Safety device according to IEC 6508 using an STM32 microcontroller. In the center and at the beginning stands the safety concept. Derived from it, you choose the off-the-shelf hardware self-test libraries from ST Microelectronics. The X-Cube STL offers a pre-certified self-test library for CPU, RAM and ROM checks. Additionally, we need some program flow monitoring and runtime monitoring. Therefore, we select the safety add-ons. This component is pre-certified and allows monitoring, logical program flow and time budget with or without an RTOS. Derived from the system specification, a CAN Open Safety stack is needed. The offer from EZED is a certifiable stack and integrates well in multiple system architectures. For separation of non-safe and safe functionalities, we derive from the specification the need for a real-time kernel with support for space protection measures. The flexible safety RTOS from Embedded Office offers all typical RTOS services. Furthermore, this RTOS includes safety measures like hardware monitoring for the MPU and stack monitoring. As a pre-certified solution, the handling of asynchronous events while keeping a high safety capability is easy. We have selected a set of software components. Now we can start defining the software architecture of the safety platform for our example project. On the right side, we see the system architecture with a target safety capability of SIL-2. The running hardware is a single STM32 microcontroller with a hardware memory protection unit MPU. The flexible safety RTOS forms the envelope which separates safe from non-safe components. We call these envelopes process. With each process, the containing software components get a personal view of the memory. In other words, we separate the running parts in the space domain. The non-safe process may contain existing software components for maintenance, failure storage and visualization. In the safe diagnostic process, we combine the selected pre-certified safety measures. These measures are the hardware self-test library X-Cube STL and the safety add-ons. The selected CAN OpenStack from EZ builds up the basis for your application in the safe operational process. How we combine the application and the CAN OpenStack, we will see later in more detail. As a result, the application team can concentrate on the project-specific application and rely on a safe platform and environment. After the definition of the safety platform, there are three activities required. Integration of four components from three vendors into a single software environment. Embedded Office offers the integration service for precisely this purpose. You will receive an integrated and ready-to-use safety platform. If you want additional safety measures or other functional features, like a secure build loader, Embedded Office can assist you with the component tailoring service. Most importantly, we believe that your engineering team's focus shall concentrate on the application. Using a flexible safety platform can protect your investment for multiple generations of products. I hope you see some inspiring points for you in our way, from the hardware up to the safety system in a project. Now, let us dive into the CAN OpenStack with EZ. Thank you Christian for this interesting subject. So, let's introduce EZ and the CAN OpenSafety Protocol Stacks in our assistance offering. It was founded in the early 90s and specialized in electronics, embedded systems, and field buses. We have several activities like product distribution, technological trainings, development of our own products, and also customer technical assistance, development, consulting, and expertise. EZ distributes embedded development tools, software quality, insurance software for static and dynamic analysis, like integration or unit testing. EZ sells also field bus tools like protocol libraries, protocol analyzers, or advert interfaces. We also sell production tools for testing of electronics, like boundary scanning test tools, but also for producing electronic boards like professional programmers. We also offer technological trainings for software quality insurance, like for standards EC 6158 or 6234 or 5128, or the hygienic standards. We also have technological trainings on field buses like CAN Open, G1939, EZCAT, EZNetIP, or PROFINET. And we also offer some trainings for concept of free time operating system, or specific operating systems, or either microcontrollers. We provide field bus solutions for our customer like protocol stacks and analyzer for most of the field buses. They are specialized for CAN and proprietary protocols on CAN, CAN Open, G1939, EZCAT, EZNetIP, CIP, and also PROFINET. We can also on demand provide some solutions for other protocols. EZ participates to ST partner program and offers assistance on software development for ST microcontroller for the HAIL library usage, RTOS integration, field bus library integration, and also generic software development. This assistance can be done in accordance with certification standard for the application. We also provide a certified CAN Open Safety protocol stack we develop on our own. The CAN Open Safety stack provided by EZ has been allowed by EZ from scratch. We do not use any open source code or third party code involving any patent or liability, royalty, or anything else and so no safety risk from this code. We develop it as a modular architecture splitting protocol management and CAN driver to allow easier porting and lower cost for certification of new variants, CPUs, RTOS, and compilers. We have a family of stack including the standard CAN Open stacks, CIS301, which means EN5325-4, or the CAN Open Safety stack which completes the extension of CAN Open Safety 304, and also the CAN Open Safety stack for the certification which is available for different certification levels of different standards. The whole protocol stack concept for CAN Open is usually based on an interface to the application. It is an object dictionary with an API. This is tied to the CAN Open software which entailed the protocol and also the CAN driver which works with the CAN hardware of the CPU. The internal architecture has a core which is ending the protocol and several services like video and SEO deals and also some core bugs to react to event and as an API to the application and the object dictionary to exchange data between application and the protocol stack. The stack also uses a CAN driver with cues for transmission and receptions. Our safety stack concept is quite the same of the standard stack but adds also some specific safety feature. You can see here in red with the SEL for safety communication mirror, the safety check and the safe objects. We see that in details in the next slide and what is exactly added and how. The internal architecture of our stack is based on two parts. The red spot for the standard CAN Open protocol, you can see it in blue, it's ending CAN Open standard services like PDOS, DO, NMT and so on. It has core bugs, API and specific object dictionary and we have the right part for the safety protocol extension. Red and orange which has its own object dictionary containing safe objects, its own API and its own core bugs. This safety part is based on two safety communication layers. Safety messages are checked on both safety communication layer channels and they are also transmitted on both channels to one part of the message on each channel. The example shown is based on model 2 implementation which uses two CAN channels meaning two different DLL, data link layer and two different physical layers but CAN Open safety standard references four different communication models. We will see them in the next slides. The first can channel is used for both standard CAN Open messages and services and safety messages and the second one only for safety messages. The model choice must be decided depending on the necessary hardware architecture and safety level needed. We can adapt the stack on any model on demand. The CAN Open safety standard presents four different models. The model 1 is completely duplicated. This means you have two different safety communication layer with two different data link layer, two different physical layer and also two different CAN network. So it's two different cable and safety messages which are in fact two CAN messages are sent one on one network and the other on the second network. Every part of the system is checking the safety messages. The model 2 we have already implemented and certified is quite similar to the model 1 but with only hardware channel this means one CAN cable but it also uses two DLL and two physical layer and each physical layer sending one CAN frame for the safety messages. The model 3 is derived from model 2 and only use one physical layer but two CAN driver and two safety communication layer. The model 4 is similar to model 3 but it means that the both safety communication layer only use one CAN channel. In any case is whatever the model you choose you must ensure with your certification authority, certification body, that you are compliant with the safety level you want to achieve. Our CAN Open stack is compliant with CAN Open and CAN Open safety extension standard. It integrates safety timing and data bit by bit control for a set of messages. It can run on any hardware having CAN controller one or two depending on the model chosen. The memory footprint is 90 kilobytes flash and 16 kilobyte RAM what may seem quite huge for a stack but it is in fact due to the certification requirements. Low code complexity and defensive programming require more code. Fully developed to be certified up to C3 level and this can be also certified without much effort to those of standard. We provide certification evidences. We decided to implement all code to the required safety level in order to facilitate integration of the library as a certified code. Just not needing neither memory nor time partitioning in the application which is easy to implement in small architectures. The object dictionary can be generated from EDS file and we also provide a free software to create and edit the EDS files. As the object dictionary is passed as a parameter during stack initialization it can be changed without re-compiling application from one start to the other. The stack can be used for any bare metal or EDS application. The version one is already in use since more than two years and has been first certified on the TMS570Ls series with higher compiler and shop the EDS. But it is already adapted to many SCN32 devices for CAN open safety or CAN open only version. We are also supporting both CAN and CAN FD controller of STM32 family with the most used compiler and an environment. GCC, STM3, IRR, KL. We can for sure that to any combination of CPU, RTOS, compiler once you have defined the one you want to use. The version one which is a certified one has limited feature like SDO expedited only protocol, static mapping for PDO, static configuration for SRDO, heartbeat monitoring only and no support of CAN remote frame. I mean the RTR, PDO or for example the not-gooding protocol. So the version two which is a standard version not certified includes SDO segmented and block transfer, dynamic PDO mapping, a serial configuration modification for the identifier and the timing aspects, the CIS303 which is the lead signaling support and the last one is the LSS protocol which is already also supported which is not mentioned here. The certified version is certified for 6158 CL3 level it could be extended to a specific 13849 standard and PL level. We have also possible certification for the standard like hybonyx, automotive, train, transportation and medical devices to meet. For the business model we have different licensing model. We can either work as a product license, side license and also some specific licensing model for the certified version. What you need to know is that you can have a start with the standard can open stack then migrate to the can open safety stack and after that buy the safety manual for example to be sure you have implemented it correctly for safety objectives and you can also buy the certification kit for the CL2 or certification kit for the CL3 level. This is all possible and just call us and we will discuss about that. Thank you for your attention. Thank you Frank for your interesting presentation and I would like to thank Christian and Louis for their presentations.