Our industry is growing at an exponential rate. Technology is advancing, the autonomous conversation is at an all-time high, and autonomy as a concept is permeating many aspects of everyday life – from cars to vacuum cleaners. Unlike just 10 years ago, where keynote speakers would present futuristic sketches, autonomy is fast becoming a tangible reality; a familiar friend that can make the world around us simpler and safer.
But with this familiarity comes expectation. In the automotive industry, for example, many of the ‘semi-autonomous’ safety features have surpassed ‘new’ and become standard for many drivers. People are expecting more and more from autonomy and companies are vying to find unique applications for the technology to enhance people’s lives.
So, in this exciting, fast-paced landscape, how do we remain competitive while also ensuring our solutions are as safe as possible?
Throughout our lives, we’ve often been taught that first is ‘best’. But in our industry, this isn’t necessarily true anymore. Sure, being first is optimal for market share – everyone knows that if you don’t have the right solution at the right time, you’ll be overtaken by competitors – but let’s not forget: what we do is all about trust. And if that trust is broken, it’s extremely difficult (if not impossible) to gain it back.
The key part of the question here is ‘balance’ – obviously safety takes precedence, but there needs to be a middle ground that enables us to be agile and respond to our customers’ needs.
You may already be familiar with the term DevOps. It’s a methodology that can be extended to incorporate safety at every stage of our development process. This is, in fact, one of our biggest challenges.
As Synopsis puts it, ‘DevOps is about removing the barriers between traditionally siloed teams, development and operations. Under a DevOps model, development and operations teams work together across the entire software application life cycle, from development and test through deployment to operations.'[1]
So, instead of getting to the end of the process of developing a software, vehicle, or machine and discovering retrospectively that different components don’t work well together from a safety perspective, we need to extend Devops to enable us to ensure safety checks are ‘built in’ every step of the way – a continuous loop of feedback where all parties communicate with one another, where regulation is incorporated, and everything is clearly traceable.
At Volvo Autonomous Solutions, a part of the DevOps strategy is called the ‘Washing Programs’, a flow of five different activities designed to help us produce the safest and most efficient feedback loops on our solution at each stage of the development process.
These feedback loops help us ‘wash’ out any bugs or inefficiencies, culminating in a customer-ready product that is developed in the safest possible way, while using agile working principles.
Firstly, we have the Domain Roll Call Program, a simple check-up (or smoke test) to ensure all our Autonomous Transport Solution (ATS) services are functioning correctly. At this stage, we’re able to diagnose and fix any simple mistakes that may have arisen during development.
Next, we have the Lunch Program, which uses fully automated world simulations to check that the critical and prioritized ATS services are still safe and productive – these are the mistakes we must ‘wash out’ first. This is done several times a day in the time it takes takes to eat lunch.
Thirdly, we have the Night Program. At this stage, we ensure all ATS services are still operating as expected. Again, we do this by placing our ATS in a simulated world to run tests automatically at large scale during the night. This is also known as regression testing.
The next stage is the Vehicle Roll Call Program. Here we use a real-world ATS placed on a test site to ensure services and components are safe for operation. Once this program is passed, the ATS is ready and approved to move on to the next stages of Autonomous Operation on the test site.
At the penultimate stage, the Weekend Program, we diagnose any performance or stability issues after long hours of operation. For this we perform extensive testing in the simulated world with our ATS to rinse out any problems.
And finally, with the Release Program, we prepare our ATS services for customer use, ensuring all requirements are fulfilled, including safety, security, and compliance. We also go above and beyond to put our ATS through its paces to receive additional feedback of unknown potential problems.
Naturally, when we consider how to balance speed with safety, we must define what ‘safe’ means to us. In the context of our company and development of autonomous solutions, we define ‘safe’ as something that doesn’t cause harm to a human being. So, any middle ground we frequent in our pursuit for agility must never cross this threshold.
Being fast is important, but ultimately safety must always come first. Sure, we can increase market share with agility, but a mistake can cost us everything.
We’re a business operating in a competitive landscape, so naturally it’s advantageous for us to be ahead of the game. We must also be reactive, creating solutions to accommodate a very specific set of consumer needs within our chosen industry segments. If we miss the boat, so do our customers.
On the other hand, it’s far better to release a product into the world when we believe it to be as safe as it possible can be, after rigorous testing at every stage of development. After all, it can take decades to build a reputation, but mere moments to destroy one. This is why we’re truly guided by safety.