My experience of the MIT STAMP workshop 2020

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.

AV STPA

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 (Sn2.1.1.4.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.