Following last year’s virtual event and a delay until an unfamiliar time in the calendar, Embedded World is back – “live and in person.” Despite the official site’s bold proclamations that we will all be “reunited”, this will be an event like no other. In the wake of COVID-19 and all that went with it, no-one really knows what the likely attendance will be. That said, more local, smaller events have recently been well attended, and that brings hope for Embedded World 2022.
The retention of the “Talque” virtual conference platform to create a hybrid event is an interesting decision. On the one hand, it is likely to include participants from around the world. On the other hand, perhaps it presents a reason not to go in person?
One thing is for certain. There is likely to be a whole lot less snow and slush around in June than in the February and March of previous years!
The official logo for Embedded World 2022
As for past years, LDRA will have a stand at Embedded World. This around time we will be occupying booth 4-505 in hall 4, and we look forward to seeing you there!
LDRA staff members will also be presenting a comprehensive array of eight papers, covering a broad range of conference tracks.
Well, kind of. Seven of those eight presentations are from LDRA – and that’s a lot from any one company. LDRA have a policy of not only selling products and services, but also sharing our longstanding expertise in the industries we serve. The Embedded World committee have a long standing policy of upholding the academic integrity of the papers they select for presentation, and that dovetails nicely. Many of the presentations we give do relate to LDRA and its products at some level – it’s where our expertise is centred! – but their focus is never “product pitch”. That leads to good papers, good presentations, and a contribution to a good conference.
Here are brief overviews of the seven LDRA papers presented at the 2022 conference. If you can’t make it to Nuremberg and would like more information on any of these topics, please do get in touch.
Safety mechanisms implemented in an “item” or SEooC (Safety Element out of Context) ensures fulfilment of safety goals in automotive electronics. Verifying the safety mechanism plays a significant role, where measuring the Diagnostic Coverage (DC) is a well-adopted principle that expresses the percentage of failures revealed by the tests.
This paper explains how software-based diagnostic tests can be created and run on target peripherals to verify the effectiveness of safety mechanisms.
The recent publication of ISO/SAE FDIS 21434 highlights the importance of ensuring that software is designed and developed with security as a primary consideration. However, it stops considerably short of saying how that should be done, making it little more than a management standard. For example, there is a stark contrast with the level of detailed guidance provided in ISO 26262 to deal with functional safety considerations.
That deficiency has left a void for developers looking to understand exactly what best practise for secure code development consists of. This paper looks to help fill that void.
System and software requirements must never be relegated to just shelf-ware! This is especially true in more Agile environments, where those requirements can be more dynamic. Those requirements cannot be considered in isolation… they need to be traced through to design to the code, and to the tests.
All requirements need to be implemented. But equally, the reverse is also true – all source code (and all tests) should be traceable back to the design and ultimately to a requirement (either functional or non-functional).
This paper helps to explain the background to bidirectional traceability, and how to achieve it. The paper will also explore the challenges of maintaining traceability in the face of dynamic (or agile) requirements.
Composability is a popular buzzword of the moment, especially in enterprise computing. Applying the same principles to embedded application development promises to open the door to more extensive software reuse.
This paper will introduce the concept of composability to newcomers to the subject and explain how it relates to modularity. It will provide an overview of what composability might mean in this context, what its limitations might be, how it might be applied in practice. It will conclude by discussing whether the principles of composability have the potential to make embedded software more reusable.
For many safety-critical applications, tool qualification is a necessary part of ensuring that a tool chain is capable of producing code of sufficient quality to fulfil the needs of the applicable standards. For all but the most critical applications, the use of TÜV certified tools is sufficient. But when the stakes are high, functional safety standards demand more.
But except for DO-330 (focused primarily on aerospace applications) and ISO 26262 (an automotive functional safety standard), there is little clarification of exactly what is necessary. And what about security-critical applications? If tool qualification is important where safety is critical, then surely it follows that it is similarly important where the concern is about security?
This paper looks to help clarify what “best practice” looks like in all these circumstances, and why it matters.
There has been an explosion in demand for embedded software across the safety-critical sectors. To cope with this steep increase while also striving for certification, improved software quality and shorter time to market, many companies are adopting model-driven development to abstract away the complexities of the applications.
This paper argues that by tying those models into an automated test process that leverages test tools used for manually coded applications, it is possible to take advantage of verification activities that are both automated and independent. It highlights how such a configuration can also ensure that any additional, manually developed code within the code base is constructed to the same exacting standards. And it explains how the automatic creation of test cases can prove all code has been fully tested where requirements-based testing is not paramount.
The process for developing new software in accordance with the functional safety standards is well understood.
However, software reuse is prevalent, and this brings complications. How should software be approved when it has developed in accordance with one standard, which may not fully conform with another? Or how should software developed for one context, be adopted in a different one?
Equally, the adoption of open source (which is typically not developed in accordance with any standard) brings its own challenges. How can that existing code base be approved for use?
This paper explores the challenges of software re-use, and how existing (especially open-source) software can be qualified for use in safety-critical applications.
In addition to LDRA’s papers being presented at the conference the MISRA situation report will be presented by our very own Andrew Banks. Andrew is not only a Technical Specialist with LDRA, he is also the Chairman of the MISRA C Working Group. He was therefore the natural choice to chair the conference MISRA stream on 21st June, and he will present the Situation Report as part of that stream.
Andrew Banks
Mark Pitchford has over 30 years’ experience in software development for engineering applications. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally. Since 2001, he has worked with development teams looking to achieve compliant software development in safety and security critical environments, working with standards such as DO-178, IEC 61508, ISO 26262, IIRA and RAMI 4.0.
Mark earned his Bachelor of Science degree at Nottingham Trent University, and he became a Chartered Engineer over 35 years ago. He now works as Technical Specialist with LDRA Software Technology.
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707