We’ll be presenting our paper on ‘Analysing the Safety of Decision-Making in Autonomous Systems’ later this year at Safecomp 2022 in Munich (which we’re absolutely STOKED about by the way!).  In the paper (sorry, no peeking until then) we analyse how we can assure the safety of Autonomous System (AS) decision-making.  Whilst we’re excited to explain our Decision Safety Analysis

Introduction

One of the significant challenges of assuring the safety of Robotics and Autonomous Systems (RAS) concerns the interactions between the RAS and its environment (including variables such as the expected weather conditions, light levels, users, other actors, and the built environment etc.). Each interaction could manifest in a novel/unanticipated situation, and these interactions may require an appropriate action to be

“Many who came before you have tried and failed” said someone famous, somewhere, once. The road towards the retrospective application of safety standards is fraught with danger, and beware the temptresses and sirens lurking within the standards who seek to lure you into the crushing depths of frustration with the mirage of simplicity.

Which Safety Standards?

With the metaphors now suitably expunged,

As we continue to research the safety of autonomous systems, we constantly evaluate the efficacy of existing safety engineering techniques.  So, what’s wrong with traditional safety engineering techniques such as HAZOP, FHA, FMECA, and even SHARD and STPA?  The short answer is probably nothing.  There is probably a lot wrong with their application, however.

Conversations with safety engineering practitioners and researchers

We’re currently designing and developing a butlerbot for use in one of our brand-new University Buildings. When I say ‘we’, I mean ‘there are some extremely clever people with whom I have the pleasure of working that are designing and building a butlerbot’. I’m playing the role of the annoying safety scientist…a role I have honed well over the years,

Failure Mode and Effects Analyses (FMECA) are a form of ‘FMEA Plus’; insofar as they add more detail to a FMEA by considering the failure paths in more granularity, and focus on asserting the criticality of failure. I deliberately avoid the use of terms like ‘determining’, or ‘establishing’ criticality, as they may not be supported by a robust data set

Competence and competencies for safety engineers is, in my experience to date, one of the most under-managed attributes of the profession. The best I can recollect is a bland, and self-complied assessment as to whether a safety engineer considers themselves to be a supervised practitioner, practitioner, or expert at certain tasks (without any robust guidance on what constitutes each level).

Despite

Are you involved in the development of safety-related systems? Are you a software safety engineer, or a software engineer with responsibility for safety?

You are? Fabulous news! Do you have time for a quick chat? You do? Brilliant – please get in touch!

Actually, regardless of whether your status matches any of the above, if you have an interest in better supporting