Skip to main content
All Posts By

Min Yu

Making CodeChecker Ready for Kernel Developers

By Blog

Contributed by Jay Rajput, ELISA 2020-2021 Mentee

The following is a brief report of my project carried out as a part of the ELISA/LFX mentorship program. 

The primary goal of the mentorship is to extend the Codechecker report converter to support a variety of tools such as: 

  • Coccinelle
  • Smatch
  • Sphinx
  • Kernel-Doc
  • Sparse


Many developers contribute to the Linux kernel. And these kernel developers are not exempted from typical programming errors in their patches, such as  null pointer referencing, array buffer overflow.  Thus, the kernel community has developed some code analyzers, such as sparse, coccinelle and smatch, for reporting such potential error patterns.

The tools mentioned above are some of the well-known tools for analyzing the code of Linux kernel. These tools however only print the warnings and errors on the command-line interface.Below is the output of some example: 

arch/x86/kernel/signal.c:338:9: warning: incorrect type in argument 1 (different address spaces)arch/x86/kernel/signal.c:338:9:    expected void const volatile [noderef] __user *ptrarch/x86/kernel/signal.c:338:9:    got unsigned long long [usertype] *arch/x86/kernel/signal.c:338:9: warning: cast removes address space ‘__user’ of expressionarch/x86/kernel/signal.c:338:9: warning: cast removes address space ‘__user’ of expressionarch/x86/kernel/pci-dma.c:20:26: warning: symbol ‘dma_ops’ was not declared. Should it be static?arch/x86/kernel/pci-dma.c:27:5: warning: symbol ‘panic_on_overflow’ was not declared. Should it be static?arch/x86/kernel/pci-dma.c:31:5: warning: symbol ‘iommu_merge’ was not declared. Should it be static?

It is tedious for developers to look up and keep track of all the errors through the text file/terminal. Manually searching the line of the error also becomes a tedious job.  Furthermore, sending the findings or comments to another developer is not feasible. Thus, it becomes very difficult for developers to keep track of all the errors. CodeChecker offers a nice and convenient web interface for viewing all the errors and even giving them some tags such as confirmed, false positive, etc. 

CodeChecker’s report converter tool provides an interface for viewing all the reports produced by the code-analyzing tools in a nice and simple web interface. It also provides the functionality to comment and mark the bugs as confirmed, false positive, etc. Thus, I wanted to extend the report converter to the tools mentioned above and also implement the functionality for importing and exporting the changes to and from CodeChecker. 

Report Converters for Analyzer Tools

My first and primary task was to create report converters for the tools mentioned above. These report converters would parse the output of tools, using regex into the format:  

File PathLine NumberColumnError MessageChecker Name

Once the report converter parses the output file of the tools it stores them into plist files which can be opened and viewed into the browser. All the plist files are stored in a folder specified by the user while running the report converter. 

CodeChecker also provides a feature to store these plist files into the CodeChecker server and then we can perform multiple operations on the reports like marking the status( confirmed, false positive, etc) and adding comments on each bug. 

Importer and Exporter for CodeChecker

The CodeChecker command-line interface provides a variety of options for listing, filtering all the runs/results present in the CodeChecker server. I have added two more commands to the CodeChecker CLI for Importing and Exporting the results to and from the CodeChecker Server.

The Export command lets the user export the findings i.e comments and review the status of one or more reports specified by the user. Below is the sample output of the reports: 

{    “comments”: {        “c54004ae9ecfb34b396b46d9e08c4291”: [            {                “id”: 7,                “author”: “Anonymous”,                “message”: “This is a confirmed Bug here”,                “createdAt”: “2020-11-28 00:05:02.034035”,                “kind”: 0            },            {                “id”: 6,                “author”: “Anonymous”,                “message”: “I am doubtful about this bug”,                “createdAt”: “2020-11-28 00:01:48.190914”,                “kind”: 0            }     },   “reviewData”: {        “00eab39f7bb399d446e0794025ab3958”: {            “status”: 1,            “comment”: “This is for the exporter function testing”,            “author”: “Anonymous”,            “date”: “2020-12-20 23:01:02.669476”        },    }}

The Importer command is used for importing the comments and review statuses sent by another user into CodeChecker Server. For importing the comments, for each comment, we check if the date, kind, and the message of the existing comment in the server and the incoming report. If any of them is different, we replace the existing comment with the incoming comment. Similarly, for review status, if the date of the review status is different, then we update the review status in the server with the incoming review. 

Use Case of Review Exchange

Consider there are two users of your System, John, and Maria. Both of them have the output of Coccinelle on the Linux kernel. 

They run the report converter of coccinelle on the output as:

report-converter -t coccinelle -o ./codechecker_coccinelle_reports ./coccinelle_reports.out

The details of how to use the report converter of all tools can be found in Report Converter Readme

They store the findings into the Codechecker server using the command:

CodeChecker store ./codechecker_coccinelle_reports -n coccinelle

Assume that there are 10 errors in coccinelle with report ids 1 to 10. John performs the following changes:

  1. Marks report 1 as false positive and comments “This is not an actual bug
  2. Marks report 2 as Confirmed.
  3. Comments on report 3 “I am not sure about the status of this bug”

Maria makes the following changes in this copy on his machine:

  1. Marks report 3 as  Confirmed and comments “This is a confirmed bug
  2. Comments on report 4 “This error needs to be handled

Now, John runs the export command and obtains the json with the name coccinelle.json

CodeChecker cmd export -n coccinelle 2>/dev/null | python -m json.tool > coccinelle.json

John sends the obtained file to Maria via email or any other communication medium. Maria downloads this file and imports the findings into his CodeChecker server:

CodeChecker cmd import -i coccinelle.json

Now, the reports in Maria’s server will be:

Report 1:Tag: False PositiveComment: This is not an actual bugReport 2:Tag: ConfirmedReport 3:Tag: ConfirmedComments: [I am not sure about the status of this bug, This is a confirmed bug]Report 4:Comment: This error needs to be handled

Pull Requests

  • Coccinelle Parser: Coccinelle report converter tool for parsing coccinelle output of kernel sources.

  • Smatch Parser: Smatch report converter tool for parsing Smatch output of kernel sources.

  • Kernel-Doc Parser: Kernel-Doc report converter tool for parsing Kernel-Doc output of kernel sources.

  • Sphinx Parser: Sphinx report converter tool for parsing Sphinx output of kernel sources.

  • Fix CodeChecker’s cmd results: Comments in the cmd results command were not fetched properly and even showed empty strings in some cases. Added a separate comments section to the details of the results command.

  • Importer & Exporter command: Exporter command for exporting the comments and review statuses for given or all runs into a json file. Importer command for importing the findings sent by another developer in a json file.

  • Sparse Parser: Sparse report converter tool for parsing Sparse output of kernel sources.

Future Work

  • Currently, the import and export commands of CodeChecker are limited only to the Command Line Interface. I would like to implement a feature to make these available in the Web Interface as well. 
  • I would like to extend CodeChecker’s report converter tools to provide proper warning classes for all the report converters.
  • I would like to add support for multiple users within a single instance of CodeChecker coming to different assessments and then moderating or reviewing them in some controlled way.


I would like to thank my mentor Lukas Bulwahn for giving me this opportunity and helping me come up with workflows and ideas for fulfilling my goals. My heartfelt gratitude towards the maintainers of CodeChecker especially Márton Csordás for being patient with me during code reviews and providing his valuable feedback. 

A look back at the 6th ELISA Workshop

By Blog

By Elana Copperman at Mobileye, Philipp Ahmann at ADIT

More than 120 registered participants, half of them first time joiners, can look back to 3 days of the 6th ELISA workshop, again held virtually due to the pandemic. It was filled with various sessions focusing on, of course, Linux and safety, but also on medical and automotive use cases as well as which role testing, tooling and development processes play to achieve the ELISA deliverables. And these ELISA deliverables should lead to making it easier to enable Linux in safety applications. This is the actual mission of the ELISA project

As this is the 3rd time that ELISA held a virtual workshop you can see the learnings from the past. Virtual get together, multiple hosts and cloud recordings of sessions support the rich experience of the workshop. 

The virtual workshop also reduces the hurdle to participate, especially as workshops are open for all and free of charge. This led again to a higher number of average participants per session compared to our previous workshops and confirms the interest in a functional safety product based on LInux. 

During the workshop, besides the regular content such as working group updates and goal settings also completely new areas of interest were presented by members and external speakers. Topics included cybersecurity expectations in the automotive world, code coverage of glibc and Intel’s Linux test robot. The impact to the Linux (Kernel) community was addressed by talks about measuring code review in Linux Kernel, statistics on patch integration or the kernel testing reference process.

The Safety architecture and automotive work groups agreed on their communication interface by sharing requirements and concepts on the Linux architecture. This enabled the momentum these two groups needed to make progress on their goals. Finally, collaboration and contributions from all our ELISA members  resulted in publishing source code and documentation on ELISA github

Tuesday Feb 2 2021

The first day began with updates from the ELISA Working Groups. As ELISA continues to chart  new territory, the collaboration between WGs is being defined.  In addition to the new interfaces described by Philipp Ahmann between the Architecture and Automotive WGs, we are beginning a joint effort between the Architecture and Development Process WG to set up a database of kernel configurations/features amenable for safety analysis.

In addition, two presentations from Intel/Mobileye focused on static analysis for compliance with MISRA and proposed test strategies for safety qualification and FFI evidences.

Both talks were very insightful, with a lot of feedback from the audience and participants turning the end of the day really into a workshop feeling like a workshop. It includes exactly the discussion which is needed when working on a Linux system ready for safety applications.

Looking forward to an even more exciting day tomorrow!

Wednesday Feb 3 2021

Andreas Gasch and Joyabrata Ghosh kick started today’s sessions with a presentation on Cybersecurity Expectations in the Automotive World.  It certainly was interesting to see how the Cybersecurity community is coming around full circle to align with the standards, processes, documentation and management much closer to what we work with in the safety community.  Perhaps in the future, we will (eventually) see Cybersecurity and Safety join forces for risk management and qualification.

Eli Gurvitz then provided a report from the Code Coverage Metrics for GLibC mentorship project (by Ashutosh Pandey) on code coverage analysis for glbc, generating quite some ripples and interest in joining the “Fun and Happiness” group aka Tool Investigation and Code Improvement Sub-WG for further work in this area.   Kudos, Ashutosh, for a great job!


Spirited discussions came up in the session on how to handle documentation in git and github. It could be clearly seen that the interest in a proper version controlled documentation repository is needed, but the standard format, if reST, markdown or LaTeX could not be concluded and reminded on the starting phase of ELISA. With the Automotive and Medical Device WGs starting to add their documents to the ELISA git repository, ELISA is taking a good iterative approach to making their work visible and structured to meet the expectations of safety experts as and the safety standards.

Day #2 was wrapped up with an extended session on defining kernel configurations for safety critical applications.  Focused on the “top down” alignment of the CONFIGs and their analysis within the context of Shuah’s work on CWE classifications for safety.  Medium term (~6 month) goal to establish a basic set of configurations and document effectively on how integrators can potentially use those configurations in safety analysis of their specific use case.  There are a lot of challenges in this area.

Thursday Feb 4 2021

The 3rd workshop day is typically focused on setting goals for the next 3 months. In addition, ELISA members spend time collaborating in long deeper dive Development Process WG’s working sessions. These sessions actually make the turn from the conference character to a workshop character. Also other sessions such as the goal settings for the next quarter leave enough room to have alignment among the active ELISA members including the Technical Steering Committee. These sessions see fewer first time attendees. We encourage new members to attend the goal setting sessions in the hope that they might be able to engage and collaborate with us on achieving our goals for the next quarter. We sincerely hope all the first time attendees will join us in our upcoming 7th workshop in May 2021.

Closing thoughts

Recapping the three days of this workshop, it is nice to see that the ELISA project is making steady progress and providing enough technical content so that the different working groups start to align and work together more effectively. The Development Process WG has become large enough to spin out smaller teams to focus on WG goals. The ELISA workshops are instrumental in collaborating on discussing current work and in collecting feedback to gain valuable insights and generate new ideas.

ELISA Workshop #6 Virtual February 2-4, 2021

By Blog, Workshop

The ELISA Workshop #6 will be held over 3 days, February 2-4, 2021.

Once again the ELISA technical community will gather virtually to continue advancing on topics and work relevant to functional safety and safe linux applications. The ELISA Workshop series are focused on education and outreach for new community members, exchanges of ideas and feedback from the linux kernel and safety communities, as well as productive collaboration to make tangible progress toward achieving the mission and goals of the ELISA Project.


Workshop registration is now closed.

All workshop attendees must register in order to receive session joining details.

Please contact for late registration requests or any other workshop related questions.

Session Schedule (UTC)

Day 1: Tuesday, February 2, 2021

12:00 – 12:30 Welcome and ELISA Strategy (Shuah Khan, Kate Stewart)

12:30 – 13:00 Summary of Safety Architecture WG Activities (Gab Paoloni)

13:00 – 13:30 Summary of Automotive WG Activities (Jochen Kall)

13:30 – 14:00 Summary of Development WG Activities (Elana Copperman)

14:00 – 14:30 Introduction of Tool Investigation and Code Improvement Subgroup (Lukas Bulwahn)

14:30 – 15:00 Summary of Medical Devices WG (Kate Stewart)

15:00 – 16:00 Effective Use of MISRA Checkers (Gabriele Paoloni, Eli Gurvitz, Roberto Paccapeli, Maurizio Iacaruso)

16:00 – 17:00 Testing Strategy for Safety Qualification and FFI Evidences (Gabriele Paoloni, Eli Gurvitz)

Day 2: Wednesday, February 3, 2021

10:30 – 11:30 Cybersecurity Expectations in the Automotive World (Andreas Gasch)

11:30 – 12:30 Code Coverage Analysis for GLibC (Eli Gurvitz, Ashutosh Pandey)

12:30 – 13:30 Intel’s Linux Test Robot (Eli Gurvitz, Oliver Sang, Philip Li)

13:30 – 14:00 Linux in Basic Safety Application White Paper Update (Jason Smith)

14:00 – 15:00 Manage ELISA Documenation in GitHub (Paul Albertella, Pete Brink, Jochen Kall, John MacGregor, Jason Smith)

15:00 – 15:30 Updates on Measuring Code Review in Linux Kernel (Basak Erdamar, Lukas Bulwahn)

15:30 – 16:00 Lightening Talks (Lukas Bulwahn)

16:00 – 18:00 Kernel Configuration for Safety Critical Applications (Shuah Khan, Elana Copperman)

Day 3: Thursday, February 4, 2021

12:00 – 12:30 To Whom It May Concern, Please Integrate My Patch (Pia Eichinger, Lukas Bulwahn, Ralf Ramsauer, Wolfgang Mauerer)

12:30 – 13:30 Networking / Social Mixer (those who express interest will be sent a separate meeting invite)

13:30 – 14: 30 Goal Setting for Next Quarter (Shuah Khan)

14:30 – 15:00 Workshop Wrap-up (Shuah Khan, Kate Stewart)

15:00 – 17:00 Kernel Testing Reference Process and Follow-ups for ELISA (Elana Copperman, Kate Stewart, Paul Albertella, Pete Brink)


Have questions about the ELISA Workshop? Please contact

ELISA Workshop #5 Virtual September 29 – October 1

By Blog, Workshop

The ELISA community will collaborate virtually September 29 to October 1.

Over twenty sessions with topics ranging from Working Group updates to deep dives into linux technologies, follow-ups from Linux Plumber Conference, and extended collaborative working sessions are being planned over the course of the 3 days.


Registration closed at 5pm EDT, Thursday, September 24th.

Attending Workshop Sessions

Please go to Workshop Session Calendar for session virtual meeting details.

Note: Only registered participants are sent session calendar invites/notifications and access the session calendar.

Session Schedule (UTC)

Day 1: Tuesday, September 29

12:00 – 12:30 Welcome to Workshop (Shuah Khan and Kate Stewart)

12:30 – 13:30 Summary of Safety Architecture WG Activities (Gab Paoloni)

13:30 – 14:00 Linux in Basic Safety White Paper Update (Jason Smith)

14:00 – 15:00 stress-ng Update (Colin King and Eli Gurvitz)

15:00 – 16:00 Software Engineering Competency Model (Peter Brink)

Day 2: Wednesday, September 30

11:00 – 12:00 Introduction to Smatch (Dan Carpenter)

12:00 – 12:30 Summary of Automotive WG Activities (Jochen Kall)

12:30 – 13:00 Summary of Medical Devices WG Activities (Kate Stewart)

13:00 – 14:00 EDAC Support in Linux and Implications for Use in FuSa system (Gab Paoloni, Chris Temple, Corey Minyard)

14:00 – 15:00 Kernel Documentation (Jon Corbet)

15:00 – 15:30 An Introduction to MISRA C:2012 (Roberto Bagnara)

15:30 – 16:00 Preliminary Analysis of a Linux Configuration WRT Some MISRA C:2012 Mandatory Guidelines (Roberto Bagnara)

16:00 – 16:30 Continuing Discussion from Linux Plumbers Dependability Session (Shuah Khan, Kate Stewart, Lukas Bulwahn)

17:00 – 18:00 Mining Kernel Development Data (Başak Erdamar)

Day 3: Thursday, October 1

11:00 – 12:00 Safety Analysis of Linux Powered Open Source Medical Device (Shaun Mooney)

12:00 – 13:00 Summary of Kernel Development WG Activities (Elana Copperman)

13:00 – 14:00 Qualification of Linux for Autonomous Driving Applications Targeting ASILB (Gab Paoloni)

14:00 – 15:00 Goal Setting for Next Quarter (Shuah Khan)

15:00 – 15:30 Workshop Wrap-up (Shuah Khan and Kate Stewart)

15:30 – 18:00 Extended Working Session on Mapping Safety Standards to Kernel Evidence (Elana Copperman)

The Linux Foundation Issues Press Release On ELISA Project Momentum

By Announcement

The Linux Foundation issued a press release on ELISA Project Momentum today.

The announcement highlights new member support, community growth and engagement, and upcoming events to learn more about ELISA’s work in advancing open source in safety-critical systems.

Community members can learn more about ELISA during the Linux Foundation’s Open Source Summit North America where Kate Stewart, is set to give a keynote speech, “Keynote: Open Source in Safety Critical Applications: The End Game.” For the first time, this event will also include an Open Source Dependability track.

The ELISA technical community is open to all to participate.

Learn more about becoming a member of ELISA.

Collaborate Virtually at ELISA May Workshop

By Workshop

The ELISA community will be collaborating virtually for the May Workshop on May 18-20. Over twenty sessions with focus ranging from new community member orientation, project strategy, work group update, to Linux kernel, lightning talks, and specific safety topics, are being planned over the course of the 3 days plus an add-on tutorial on your first kernel patch on Thursday.

Please Register by 5pm EDT, Friday May 15 to receive a calendar invite for the sessions on the schedule below. We look forward to your participation!

Monday, May 18th

11:00 – 11:55 UTC

ELISA Newcomers Introduction: Lukas Bulwahn & Elana Copperman

12:00 – 12:25 UTC

Welcome ELISA Workshop: Kate Stewart & Lukas Bulwahn

12:30 – 13:25 UTC

ELISA Strategy Update: Chris Temple 

13:30 – 13:55 UTC

Linux in Basic Safety Applications: Jason Smith

14:00 – 14: 55 UTC

All about Kernel CI: Shuah Khan & Kevin Hilman

15:00 – 15:55 UTC

Medical Devices Working Group Update: Kate Stewart

16:00 – 16:55 UTC

Software Lockstep: Corey Minyard

17:00 – 17:55 UTC

First Attempts at Data Analytics of Kernel Patch Review: Anmol Singh 

Tuesday, May 19th

9:00 – 9:55 UTC

CRC implementations, safety and reliability: Elana Copperman

10:00 – 10:55 UTC

Measures and techniques tailoring by property equivalence in context of IEC 61508: Nicholas Mc Guire & Jens Petersohn

11:00 – 11:55 UTC

Kernel Development Process Working Group Update: Elana Copperman

12:00 – 12:55 UTC

Linux for safety characteristics: Shuah Khan

13:00 – 13:55 UTC

Safe Linux features (.config settings): Elana Copperman

14:00 – 14:55 UTC

Safety Architecture Working Group Update: Gabriele Paoloni

15:00 – 15:55 UTC

Callgraph Tool and its Use for Architectural Analysis: Primary Author/Presenter: Marijo Simunovic

16:00 – 16:55 UTC

Lightening Talk Session: Lukas Bulwahn

Wednesday, May 20th

9:00 – 9:55 UTC

Syzkaller Fuzzing, Handling Syzkaller Repros as Known Issues, and Extensions to Syzkaller: Primary Author/Presenter: Jouni Hogander & Jukka Kaartinen

10:00 – 10:55 UTC

Stress-ng for kernel testing: Colin King & Eli Hibshoosh

11:30 – 11:55 UTC

ELISA-AGL Working Group Session: Naoto YAMAGUCHI

12:00 – 12:55 UTC

ELISA Automotive Working Group Kick off: Gabriele Paoloni

13:00 – 14:25 UTC

Fault hypothesis and technical measures to ensure integrity on a process memory within a mixed criticality environment: Thomas Brinker

14:30 – 15:00 UTC

Workshop Wrapup: Kate Stewart & Lukas Bulwahn

Thursday, May 21st

13:00 – 13:55 UTC

Tutorial to my first own kernel Patch: Shuah Khan

Lyon Safety Summit Session Slides Now Available

By Announcement

We had a successful and well-attended Open Source Software in Safety-Critical Systems Summit on October 31, 2019 in Lyon. Here is the list of sessions, abstracts, speakers, and their presentation slides (linked from the session titles). 

9:00 – 9:30 Speaker: Lars Kurth
The Road to Safety Certification: How the Xen Project is Making Progress

Abstract: Safety certification is an essential requirement for software that will be used in highly regulated industries. The Xen Project, a stable and secure hypervisor that is used in many different markets, has been exploring the feasibility of building safety-certified products on Xen for the last year, looking at key aspects of its code base and development practices.

In this session, we will lay out the motivation and challenges of making safety certification achievable with open source and the Xen Project. We will outline the process the project has followed thus far and highlight lessons learned along the way. The talk will cover technical enablers, necessary process and tooling changes, and community challenges. Safety certification for commercial software based on an open-source hypervisor is an exciting and challenging goal.

9:30 – 10:00 Speaker: Anas Nashif
Introduction on Zephyr

Abstract: Open-source software development and how open-source projects are run is often seen as incompatible with functional safety requirements and established processes and standards. Open-source has been used on a regular basis in applications with safety requirements however in most cases the open-source software is forked and developed behind closed doors to comply with safety standards and processes and using existing infrastructure and tools not common or not available in public and in open-source.

This talk will show how the Zephyr project is moving to a new development model and methodology that uses existing and public tools to address many of the requirements and foundations that would help with using Zephyr in applications with functional safety requirements.

10:00 – 10:30 Speaker: Aymeric Rateau
Introduction on ELISA

Abstract: Aymeric will depict the background and challenges of using Linux for safety critical embedded applications : cultural clash of OSS community vs. classical waterfall development, many difficult to access and understand standard specifications, custom and expensive developments, etc.

On this basis, Aymeric will introduce ELISA’s current status, direction and goals. 

11:00-11:30 Speaker: John MacGregor
Walk Before We Run? Nope, Let’s Get Our Heads Up First

Abstract: There is quite a buzz at the moment about safety-certifying open-source software. The initial discussions have centered around which standards to use and which domains/industries/applications should be certified first.  Some of the proposals were for extremely complex state-of-the-art domain applications which have, as yet, not even reached the stage of commercialization.  A pretty common aspect of most of these discussions focus on the end state of the certification approaches and ignore the question of “how do we get there”.  Borrowing from a tired old metaphor, sometimes it’s like we’re talking about climbing Mount Everest when we haven’t even learned to walk.

It’s not like we’re starting from scratch, however.  There are time-honoured principles for going about certifying new products.  Some open source projects have already learned some lessons from their certification efforts while other projects have some good insights about how they want to approach certifying their open source software.  There are possibilities to cooperate and learn from each other.

This talk will present the basic issues facing a project that wants to start a safety-certification initiative and some of the options that they have.  It focuses on incremental and evolutionary approaches that minimize the risk that the initiative will fail.

11:30-12:00 Speaker: Naoto YAMAGUCHI
Functional safety and Quality Management issues in AGL Instrument Cluster Expert Group

Abstract:  AGL Instrument Cluster Expert Group want to create a base platform for Cluster.  There are different system requirements between IVI and Cluster.  Instead of a system based on  the conventional IVI system, it is necessary to consider a new system suitable for Instrument Cluster.

Functional safety and Quality Management is one of the important issues.  Instrument Cluster requires higher quality management than the IVI system.

We want to solve this issue by collaboration with the ELISA project.  In this presentation we share to ELISA members “what we aim” and “our architecture”.

13:30-14:15  Speaker: Chris Temple
SW Safety Elements out of Context – Understanding the Not Understandable

Abstract: The safety element out of context (SEooC) is popular amongst SW developers seeking to develop SW for safety critical systems. The ISO 26262 standard defines a SEooC as a “safety-related element which is not developed in the context of a specific item”. A safety-related SW element is a SW component or SW unit “that has the potential to contribute to the violation of or achievement of a top-level safety requirement”.

According to the Oxford dictionary “context” is “the circumstance that forms the setting for a statement in terms of which it can be fully understood”, and “out of context” as “not fully understandable”.

This presentation looks at the role of context, the implications of developing SW out of context and what this implies when SW is put into context later on by means of an example. It concludes by musing on whether something that is “not fully understandable” can be safe.

14:15-15:15 Speaker: Shaun Mooney
STPA: Developing safety and security requirements of complex systems and STPA Documentation Tooling

Abstract: Systems are becoming increasingly complicated, and current safety techniques which focus on failure rates of individual components are ineffective to handle such complexity. With systems like Linux, it is vital to have a proper tool to derive requirements from which we can build safe software. If the requirements are inadequate, then the software can pass every test while still having fatal flaws. STPA (Systems Theoretic Process Analysis) is a top down, systems approach to safety and security, which allows us to analyse complex systems, identify safety and security issues, and develop requirements.The first part of the talk will give an overview of why we need to incorporate safety and security at a system design level, explain the concepts of STPA, show how to manage complexity using an example of an Autonomous Vehicle and show real world examples of how to develop safety and security requirements.

Codethink have released an open-source tool for documenting STPA, which is hosted on flathub: The tool facilitates the storage of analysis data and automates the production of analysis documentation. It handles all of the analysis data in a tree structure, automatically managing reference numbers for all items, and data items can be linked and cross-referenced in the structure. Having the tool manage all cross referencing and numbering reduces a lot of effort. Everything is saved in plain text, which means the analysis data can be version-controlled easily. The second part of the talk will give a summary of why better tools are needed for STPA, and explain what the tool does with a live demo. The talk will conclude by pointing out improvements that can be made, next steps, and how the community can get involved in the open source project.

ELISA Workshop, Brussels, January 30-31, 2020

By Workshop

Date: 2019-01-30 and 2019-01-31

Time: 9:00 to 17:00 CET  

Venue:  Toyota Motor Europe Technical Centre B 

Meeting Room: VB1-11 (1st floor)

Address: Hoge Wei 33, 1930 Zaventem, Belgium (Entrance at: Hermesstraat28, 1930 Zaventem)

This workshop will be focused on technical topics to further evolve the discussions from the second workshop held in September.  Initial suggestions currently include AnnexQR, IVI and openAPS use cases, and bridging multiple safety standards and etc. Anyone interested in software quality management around the Linux kernel, software safety management and engineering of pre-existing, tool development for Linux kernel development and investigations of the Linux kernel sources should attend.

The workshop is intended to be considered an open discussion and shall allow groups to start small project work on the topics we identified interesting, based on the different skills and interests of the participants. The exact agenda is open to discussion on the ELISA mailing list and up to the participants to finally decide.

Registration: The workshop is open to everyone, but you would need to register for the workshop to help us with event planning.

Recommended Hotels in Brussels centrum (Note – Toyota has no special rates for guests)

Ibis St Catherine

-rue Joseph Plateau 2, 1000 -BRUSSELS

-Tel :(+32)2/6200426

Ibis Grand Place

-Rue du Marché aux Herbes 100 , 1000 -BRUSSELS

-Tel :(+32)2/6200427

Best Western Carrefour de l’Europe(Grand Place)

-Rue du Marché aux Herbes 110 , 1000 -BRUSSELS

-Tél.+ 32 (0) 2 504 94

CrownePlaza Brussels

-Le Palace, Rue Gineste 3, 1210 Bruxelles-Contact: +32 2 203 62 00, 

If you have any further questions, please join and ask them on the ELISA mailing list.