I recently digitally attended the 2020 STAMP workshop, hosted by MIT. This was originally planned to be in Boston in March, but for obvious reasons was moved. The conference was split over 3 weeks, instead of the 1 that was scheduled in March, to ensure that the talks were at reasonable times for as many people as possible. This worked nicely as it meant I could dip into the talks I was particularly interested in, and there was little impact to my week.
I found the digital workshop to be strange in comparison to in person. On the positive side, it was far more accessible. There were 2,200 people registered for the conference, over 73 countries, which is a large improvement on the number of people who attended in person in 2019. It was hosted on zoom and there were little / no technical problems for the talks that I watched. The negative was the lack of technical discussions I could have with participants, and the lack of networking opportunities. Although the chat window was active on zoom, I found it was a poor replacement for being able to go and talk to somebody in person during breaks. Along with zoom they used slido, where viewers could ask questions anonymously for the hosts to answer. Again, this was frustrating as there were several questions of interest to me, but there was no way of contacting the people who asked them.
One massive positive that has emerged from this workshop is a STAMP slack channel. I'm pleased and surprised by the uptake in this, as there seemed to be little interest in this kind of thing in the past. My suspicion is that covid has forced people to become familiar with more tools like slack. What is great to see is the STPA community forming. For too many years it has seemed like all of the STPA activities have been coordinated by MIT, so it's great to see people discussing and sharing information directly. Hopefully this will help to accelerate the use of STPA, and encourage more knowledge sharing and collaboration.
Specifically of interest on the slack channel, there are some people who have conducted STPA of medical devices (artificial pancreas systems and respirators) which we are working on ourselves with ELISA (Enabling Linux in Safety Applications). Kate Stewart from the Linux Foundation runs the ELISA medical devices group, and has been in touch with various people who are keen to get involved and review / collaborate on our analysis which is great. There is also interesting talk on a cloud computing channel around STPA for software systems, and there are some large software companies like AWS and Netflix taking interest which is great to see.
It's worth noting that I saw the work we did with MIT on the Apollo autonomous driving platform came up a few times, mainly in John Thomas' intro slides, his presentation on STPA mistakes (we were the good example) and Michael Schmid's thesis appears to make use of the work we did (Michael worked with us on the project briefly).
Talks and Points of Interest
There were many talks, including a few sessions of short 15 minute talks, so I've highlighted the ones of particular interest. In general though, I have two main concerns that keep occurring at STPA events. The first is that there feels like a lot of "preaching to the converted". Most of the effort is trying to convince everyone of how great STPA is. For those of us who use it already, this gets a bit dull, and I'd be much more interested in more advanced technical talks on its use. This leads into the second problem, that so much of the work is IP protected, so there is still a major lack of detailed work in the public, and the talks largely don't go into many interesting details.
However, some interesting points / talks that came up:
STPA is being included in safety standards, listed here.
It is also mentioned in the Uber Autonomous Driving safety case (Sn22.214.171.124.1.1.1). This safety case is widely recognised and used, so the mention of using STPA is a really positive selling point.
Akami have produced some handout "cheat sheets" to assist when doing STPA.
When STPA Results Surprise You - This talk compared results from different analysis techniques such as HAZOP, Fault Tree and FMEA, on a practical example of an industrial cooling system. I saw this example explained by John Thomas in the European STAMP workshop last year, and it is a very good example of why you shouldn't just analyse component failures, as in this system adding redundant sensors actually compromised the overall safety of the system. Even if nothing fails and everything works as designed, the way the sensors interact with each can cause unsafe states. It highlights the shortcomings of the other techniques.
Facilitating and Implementing STPA. - I've seen this talk evolve over several events, but I still find it relevant now. It is all about how to incorporate STPA into the workflow, the kind of team you should have perform the analysis and how to teach and manage people on their first projects using it. There's nothing particularly groundbreaking here to be fair as a lot of the points seem like common sense, but they’re things that get overlooked far too often, such as the team should consist of a mix of skills (such as hardware, software, safety expertise, human factors etc) and really like a lot of things the only way to teach STPA is to have a real system and try it with somebody who has done it before. What was interesting in this talk is on slide 37 John talked about reasons to publicise that you are doing STPA. He mentions a company who did all of their work in the open, as they wanted to be "recognised as a leader" and that they "were first". My suspicion is that this is Codethink he's talking about, but he never actually mentioned us by name.
Using STPA to Create a Conceptual Architecture - This talk was particularly interesting. It described the benefits of adopting STPA early on in the concept and design phase (rather than just analysing a "finished" system). It shows how using STPA helps to make design decisions, and how to iterate the analysis accordingly. We found similar things when working on the CRASH robots (although we didn't document the benefits STPA had on the concept design phase at all).
SAE STPA Recommended Practice Task Force Update - This SAE taskforce is dedicated to applying STPA to automotive applications. Mark Vernacchia from GM gave an update on the work of the taskforce. I met Mark in Boston last year, and was added to the taskforce. Unfortunately I haven't been as involved as I wanted (the regular meeting slots are 11pm on a Thursday so I haven't joined many), but it's nice Codethink got a shout out as a member anyway (slide 11).
This workshop has highlighted just how popular STPA is becoming, along with the many gaps there still are in it's practical use. I think in particular the field of STPA with software has large potential, and Codethink still appears to be at the forefront of the activity here.
- RISC-V: Codethink's first research about the open instruction set
- Meet the Codethings: Safety-critical systems and the benefits of STPA with Shaun Mooney
- Why Project Managers are essential in an effective software consultancy
- FOSDEM 2021: Devroom for Safety and Open Source
- Meet the Codethings: Ben Dooks talks about Linux kernel and RISC-V
- Here we go 2021: 4 open source events for software engineers and project leaders
- Xmas Greetings from Codethink
- Call for Papers: FOSDEM 2021 Dev Room Safety and Open Source Software
- Building the abseil-hello Bazel project for a different architecture using a dynamically generated toolchain
- Advent of Code: programming puzzle challenges
- Improving performance on Interrogizer with the stm32
- Introducing Interrogizer: providing affordable troubleshooting
- Improving software security through input validation
- More time on top: My latest work improving Topplot
- Cycling around the world
- Orchestrating applications by (ab)using Ansible's Network XML Parser
- Red Hat announces new Flatpak Runtime for RHEL
- How to keep your staff healthy in lockdown
- Bloodlight: A Medical PPG Testbed
- Bringing Lorry into the 2020s
- How to use Tracecompass to analyse kernel traces from LTTng
- Fixing Rust's test suite on RISC-V
- The challenges behind electric vehicle infrastructure
- Investigating kernel user-space access
- Consuming BuildStream projects in Bazel: the bazelize plugin
- Improving RISC-V Linux support in Rust
- Creating a Build toolkit using the Remote Execution API
- Trusting software in a pandemic
- The Case For Open Source Software In The Medical Industry
- My experiences moving to remote working
- Impact of COVID-19 on the Medical Devices Industry
- COVID-19 (Coronavirus) and Codethink
- Codethink develops Open Source drivers for Microsoft Azure Sphere MediaTek MT3620
- Codethink partners with Wirepas
- Testing Bazel's Remote Execution API
- Passing the age of retirement: our work with Fortran and its compilers
- Sharing technical knowledge at Codethink
- Using the REAPI for Distributed Builds
- An Introduction to Remote Execution and Distributed Builds
- Gluing hardware and software: Board Support Packages (BSPs)
- Engineering's jack of all trades: an intro to FPGAs
- Bust out your pendrives: Debian 10 is out!
- Why you should attend local open source meet-ups
- Acceptance, strife, and progress in the LGBTIQ+ and open source communities
- Codethink helps York Instruments to deliver world-beating medical brain-scanner
- Codethink open sources part of staff onboarding - 'How To Git Going In FOSS'
- Getting into open source
- How to put GitOps to work for your software delivery
- Open Source Safety Requirements Analysis for Autonomous Vehicles based on STPA
- Codethink engineers develop custom debug solution for customer project
- Codethink contributes to CIP Super Long Term Kernel maintenance
- Codethink creates custom USB 3 switch to support customer's CI/CD pipeline requirements
- Codethink unlocks data analysis potential for British Cycling
- MIT Doctor delivers Manchester masterclass on innovative safety methodology
- Balance for Better: Women in Technology Codethink Interviews
- Introducing BuildGrid
- Configuring Linux to stabilise latency
- GUADEC 2018 Talks
- Hypervisor Not Required
- Full archive