 Welcome to this presentation at ST DEF CON 2020 about accelerating functional safety projects using pre-verified software components. My name is Christopher Seidel. I am a Senior Product Manager in ARMS Development Solutions Group. Here's the agenda. I will first give you an overview of the software development process and about functional safety in general. Then I'll introduce you to the tools and building blocks that we offer. I present an application note that explains how to use our tools and software with the libraries that S3 Microelectronics provides. Before wrapping up, I'll show you how a practical approach to the software development process takes advantage of the tools that ARMS is offering. Let's start with a closer look at the software development process and functional safety in general. What does functional safety actually mean? The ISO 26262 gives an easy answer to that. But what does it mean? How can we ensure that systems function correctly? The products must be properly specified and developed accordingly and faults must be detected and controlled. Systems with a safety level of nominal are helpful rather than essential. Usually a user can act to avoid hazards if aware of a fault. Safety critical systems are relied upon to always function. In case of failures, there's a high risk of hazard and loss of life. This is the well-known V-Model, which is a graphical representation of a system development life cycle. It describes the various development steps. The requirements on the left side should be verified to ensure that you build the right thing. However, validation should also happen directly on the left side while you are creating the requirement specification. This V-Model approach is also supported by various ARM products. For example, the ARM processors meet basic safety requirements by including access protection via MPU or stack limit registers. Fast models can be used to run early prototypes of the software architecture without the necessity to use target hardware. Static code analysis and MISRA coding rules help already during software development. MDK offers integration with many third-party tools here. Code coverage is the matrix for test completeness and we support this via trace and simulation models. Using our debug adapters you can verify execution times and with the new event recorder you can even obtain execution statistics. Fault injection is important to validate safety or security aspects of a system. Our models avoid that you destroy any equipment and even allow test automation. This also enables continuous integration of your software development. Today very important for the agile development style where you add additional requirements during development. Functional safety is required across multiple market verticals. Some are very established such as industrial, transportation and avionics. Others are more nascent such as consumer and medical. Automotive is of course a key vertical for ARM but we look to scale across adjacent markets with our safety solutions. While the V-Model is generic and should be applied to all development projects, the safety standards mandate for it. Each industry has its own safety standard however their requirements are very similar. Safety is about reliable operation. Systems should detect failures and in case of failures operate in a safe mode. A safe mode could be as simple as switch off the device but sometimes it would require to run a motor at full speed. And therefore this safety standards categorize safety requirements to the end system using safety integrity levels. Each standard is slightly different but basically you need to analyze the risk of your system. And when you think about it it applies to many systems. One of our customers builds window lifters for the car industry. And one of the risks is that you can cut a finger off with a little window lifter. For example when kids play at the back seat and their parent closes a window. While this might be categorized as likely it does not kill the kid it's just severe. So you will qualify that risk as 3. Modifications to the glass or ceiling of the window may further reduce the risk so that you might be able to qualify this as unlikely. This does not seem to be overly intuitive but there is a statistical background. Each of these levels probability or severity is roughly a factor of 10 apart. Once you have analyzed the potential risk of your system you can map the results to the SIL level of the related standard. The SIL maps the acceptable risk effectively to the development process. And this impacts the design principles and test efforts. Here you see a very small portion of the ISE 6150A requirements. The full standard has several pages of them I give you here just an impression. For example table A2 describes software design. Table B2 is about testing. These tables either recommend or highly recommend certain techniques or measurements that you should apply to your system. You can clearly see that higher SIL levels have higher requirements. Or sometimes you cannot use various techniques such as dynamic memory allocation as for example SIL 3 and SIL 4 highly recommend statistic resource allocation. System designers are therefore interested to reduce the SIL level for their development. You may therefore implement the safety critical part in relatively simple systems to isolate from other parts that are not safety relevant. How can you accelerate the development of a functional safety application? There are a couple of components that are available today that help you to reduce the time to market here. First of all you can select a Cortex processor that fits your needs. As you can see here there are many options available for all the different SIL levels up to A SIL D. This gives you the confidence that you can meet your target SIL level with your selected hardware which is the basis that your software is running on. Then you should use pre-qualified tools. Since many years we have a qualification kit for the ARM compiler. Our current compiler is LLVM based and supports the latest C++ standards. We have got good traction in the automotive industry as this is relevant for ADIS. We also offer long-term support and maintenance for these compilers. Important as many products require many years of development and support. And you do not want to change a compiler version but only get specific fixes for potential defects. Next choose software components that are already pre-certified for functional safety applications. For that we have introduced a runtime system for functional safety applications, ARM FUSA RTS. It is a set of software components certified for use in automotive, industrial, medical and railway applications with the highest safety integrity levels possible for software. FUSA RTS has received corresponding certificates after strict analysis and review by TÜV Süd, a well-known certification organization. FUSA RTS includes a real-time operating system based on the industry standard KylRTX, a debug component for timing and events analysis, the core specific part of SAMHSA's core and the C-Library specifically designed for functional safety applications. A device-specific software test library, STL, is mandatory in several applications and can be easily integrated. I touch on this point later when I explain how we do that with the STLs provided by ST Microelectronics. The FUSA RTS is certified in combination with the Safety Qualified ARM Compiler 6. This fully qualified software and tools environment lets you concentrate on the development and certification of the end application. The KylRTX 5 real-time operating system is leading in the market for many years and offers features like dynamic and static memory allocation. Dynamic memory allocation simplifies configuration efforts during development. The built-in RTOS awareness in MDK makes it easy to identify the memory requirements and change it to static memory allocation. Static memory allocation is mandatory for several standards depending on the software integrity level. The event recorder is an integral part of the FUSA RTS and helps during software development by providing kernel information, user event annotations and timing information of the application. Analysis of timing behavior is a requirement of integration testing during the software development process. The FUSA SAMHSA's core implements the basic runtime system for a Cortex-M device and gives you access to the processor core. It's a certified version of the standard SAMHSA's core for Cortex-M. The device-specific part of SAMHSA's core is not part of the certification, but as it is reduced to access definitions only, it is easy to verify. The FUSA C-Library implements a subset of functions specified in the ISO C99 C-Language standard and it comes with usage guidelines and examples on how to work effectively with it. It runs on close to 8,000 Cortex-M-based devices available in the market and is closely integrated into KiLam DK for best productivity. In the previous slide I was talking about a software test library. You may have heard that SD Microelectronics is offering such a piece of software. What exactly is an STL? STLs provide added diagnostic coverage required by several standards. For example, in automotive for ACIL-C and D or CIL-2 and CIL-3 in industrial applications. ARM STLs cover the processor and core peripherals and can execute as part of the application, for example in a separate process. The tests are non-destructive if schedulers save and restore is used. To cover the full device, the silicon providers such as ST Microelectronics may expand it for example to cover DMA or other system components as shown here. ST Microelectronics provides the XCube STL libraries that implement diagnostic tests for STM32 devices and are certified for IEC 61508. They are created with ARM tools in mind and can be used together with a qualified ARM compiler. We have an application note available that explains details on how to use XCube STLs with FUSA RTS. It summarizes the safety requirements and explains how to use STLs and FUSA RTS in an application. It also touches on how to determine the correct operation by using advanced debug features of microvision. An example shows the usage on an STM32 F4 target. You can download the app note via kyle.com-aap. Let me quickly show you the project. I have opened the project file that is coming with the application note and in its abstract.txt file you find some instructions on the requirements and what you initially need to install. Of course you need a FUSA RTS software pack and a device family pack for the STM32 F4 device. But you also of course need the XCube STL files that are not shipped with the application note because obviously this is the IP of ST and you need to register on their website first because you can get these files. Once you have done that you can copy them simply into the project and they are available here. This abstract also explains how this is built up. We have one app main that creates the threads that are running here and the application note basically assumes that you add the STL routines to an already existing project. In this case it was a Blinky project so there is a thread for an LED toggling and a button thread that is basically checking the status of a button on the nuclear board that is used here. And in addition there is a thread that performs the STL tests every 5 seconds. Now before taking a closer look to the code itself let's take a look at the software components that we have here. So you can see that SAMHSA SCORE and Kailar TX as well as the compiler are all coming from the FUSA pack. So you see the documentation here to the FUSA pack. So these components that I have explained before that are part of the FUSA runtime system are already used in this project here. Now let's open the main.c file and we basically can check for this app main. So you see down here it's the app main thread that basically just creates all the three other threads like the button thread, the LED thread and the STL thread. I won't take a closer look to the button and LED that's just standard stuff that is available in a Blinky project. Here we have the thread that is running the STLs and basically it calls some SVC functions and the supervisor call functions because for the STL code to run we need the privileged mode and so we are using this call to an SVC so that we can switch basically to the privileged thread mode and run the actual test from there. So if you take a look at the SVC user.c file you see that there are a couple of tests. So the SVC STL RAM test for example, the STL flash test and those are then calling actually the tests that are in the STL run.c file. So we have for example a CPU test here, the flash run test and down here the RAM test and one additional point here for the flash. So to test the flash some CRC values have to be calculated over the content of the flash and this is actually done here. After the generation of the flash file we run the STM32Q programmer and let it calculate the CRC values that are then later used to basically check if the content of the flash is correct. That's for a quick introduction into this project. The application note of course explains the background of all of this in much more detail. It also shows you the correct output when you are connected to a target. As said this is for an STM32Nucleo board so it's quite easy to obtain and you can check it out for yourself and see how this behaves. I now show you how you can apply all of this in your application development so that you can get your safety certificate faster. What different types of software testing are required during the design phase? Small parts of the code are tested on a functional level during unit tests. As you put these small parts together you start to test the integration. This verifies the correct behavior of the components working together. Next you apply functional testing to see if the overall functionality works as specified. The final system tests check if all requirements are met. Today you will do this testing in a continuous integration environment where the tests are run once you commit code to your repository. Our fast models help you here as they have no hardware dependency and can scale with your server environment. Fault injection, the application of test stimulus and repetitiveness are great advantages when using models especially for unit tests. Later you have to do workload testing on the prototype hardware to verify the overall system behavior. Here our debug adapters help you to create an automated test stand that can run independently from human interaction. Using the advanced analysis features of the debug adapters you can verify the timing easily. Models are always available while prototype hardware is usually in short supply. In a traditional environment you first need to develop the hardware. Once this is finished you can start testing your software running on it. Using models you can run 1000 tests in parallel which gives fast feedback to the programmer using CI tests while the hardware is being developed. The tests themselves are reproducible while hardware can lead to different results due to timing issues. These regressions are hard to verify. Test hardware is also fragile. For example JTEC connectors might have a loose contact and does not work reliably. Especially for the unit tests models work much better as you can apply input stimulus via test data. Also you can use the large amount of memory that is available on test machines instead of the constrained embedded target device. As mentioned before, code coverage is a matrix used during testing. It is important to have a smooth process here. And therefore our tools work without any software annotations. As NASA says, we fly what we test and we test what we fly. I believe this is important for many systems. Several models support branch coverage. Using ProDebug and TraceAdapter uses Trace to get accurate code coverage information directly from the silicon. The color coded information helps you during test code development as it is updated during execution. And all this code coverage data can be exported for reporting which is important for test integration. Here you see the integration into your Jenkins CI system. This helps you to validate a system constantly during development. We are using this approach during the development of our FUSA runtime system. When we were visiting one of our key customers they explained us how difficult it is to validate worst case execution timing of a real-world system. We have a technology that helps here a lot. The event recorder is based on annotations in your system on critical execution points. The events can be filtered and the ones you are interested in are recorded in an event buffer. Each event gets a timestamp along with other information that is formatted by a debugger using an XML description file. This keeps the software overhead in the embedded system down to a minimum. Compared to printfdebug style that was used previously by the customer an event is recorded in less than a microsecond and events that are filtered out take just a few CPU cycles. And the good thing about it is as it is safety certified you can leave it in your final production code. We have initially developed this technology to analyze software stacks that are a black box to the user. Our RTOS kernel awareness works this way and all our middleware components are annotated with events. But it is also easy to apply to user code to get deeper insights into the operation of your application. And with event statistics you can record minimum and maximum execution times of your application in up to 64 different slots. You just need to add start and stop events to your code. Then the debugger shows you not just timing statistics but also records the calls that cause minimum and maximum timing. Again, since this technology is part of our certified FUSA runtime system you can leave it in your production code. Let me summarize the benefits of MDK when using it for developing for functional safety. For static code analysis and miserable checking we have close integration with third-party tools. Code coverage can be derived from models and real hardware with reporting mechanisms in place for CI environments. For memory usage analysis we offer stack watermarking, counters for the various RTOS objects and linker-based stack analysis. This helps you to find the right memory requirements when going to static allocation. To analyze the overall timing of your system we have multiple tools in stock that can even stay in the production code. For CI integration we offer remote interfaces that help you to run unit test frameworks in Jenkins CI environments. Finally, hardware-based test automation is supported using debug scripts and using the IO pins on our debug units to interact with the device under test. Let me summarize the presentation. With our software tools and the software building blocks we make it really easy to create products that require safety. We support the development process with compiler, IDE and debuggers. Simulation models are today often an integral part of the development process. For example, automotive projects frequently request them. And our innovative debug adapters support, for example, test IO for automated validation runs. Our tools are complemented by the runtime system that I described. It is based on SAMHSA's, a widely used software standard. As explained, we utilize the hardware features of the Cortex processors and our customers do not need to worry about tools as we supply a complete system. One of the big challenges is the final safety certification. We are investing today to help solve these challenges. The safety-ready program spans all the arm technologies that are needed for safety solutions. We are doing more of the work around functional safety upfront to simplify the overall certification process for our partners and customers from Silicon to module to end-user application. We are delivering a broad range of safety certifiable IP, the right set of certified software components and software tools like our software test libraries, compilers and certified RTOS. Our robust methodologies and certification includes comprehensive safety documentation. We work with third-party certification authorities to pre-certify our products for relevant safety standards. Thank you for listening.