Having spent more years than I perhaps want to admit in the technology sector, I have always had one single, fundamental guiding principal that I ask myself over and over – “What does the customer want?” Of course, there are variants on the theme: “What does the customer need to be successful?”. Naturally, as part of the discovery process, I do sit down with my customer or partner and ask them directly. That’s the best source of information and, assuming you listen and then deliver, the best chance for mutual success. However, it’s not always that simple. Technology by its very nature is always enabling new and exciting use cases, products and applications driven by innovative companies employing smart people. The challenge is that “bleeding edge” often means not all the requirements are known as early in the development cycle as we’d like.
I’ve also observed another fundamental mindset shift over the years working with some of these innovative organizations. Part of the product development thought process considers the strategic impact of the decisions being made now. What I mean by that is: how could the choices being made today impact future generations of the product under development? Can innovation be accelerated by introducing the next generation a little earlier because scalability and reuse was considered from the beginning? The answer is generally yes but it doesn’t come for free. There are always trade-offs to be made.
Safety in Context
“So what?” I hear you ask. Well, let me put this preamble into a context that’s a little closer to home – safety. Perhaps more specifically, functional safety. Developing products and solutions for safety requires extra effort, heightened skillsets, and more time, which is ultimately measured in terms of cost and schedule. As an example, think about a vehicle’s airbag. I’m going to dramatically oversimplify modern airbag control systems to make a point. Fundamentally, the use case is simple – if the vehicle crashes, the airbag deploys. There is a sensor that detects the crash typically based on a G-force threshold and an explosive charge that actually deploys the airbag. The thing with airbags is that you hope it never needs to do what it’s designed to do but at that unfortunate moment when it is needed, it better perform its job perfectly. So, additional functions are designed in to continually monitor the integrity of the control system. In the event of an issue or fault, a signal can be sent to show that a service is required – the dreaded engine warning light. With this example, it’s easy to see that this additional safety function requires extra effort, time and cost in terms of design, verification, validation and safety certification.
Let’s now look at the wider implications. The additional functions discussed above that ensure safe and correct operation of the system, including diagnostic and monitoring activities, span both the hardware and software domains. For example, these systems would typically include Error Correction Code (ECC) capabilities within the silicon to provide additional integrity on the device buses. The addition of an external watchdog microcontroller would be another example of hardware. From a software point of view, the whole ‘stack’ needs to be considered safe. This would include the real-time operating system (RTOS), applications, drivers etc. It is this particular area that I want to discuss in further detail.
Why Open Standards?
Generally, for any company that is developing both hardware and software products, the investment in the latter far outweighs that of the former. Given this level of investment in software, devising ways to drive scalability and reuse of said investment is becoming increasingly important and simply put, if done correctly, can result in a significant competitive advantage. This issue is compounded when safety comes into play. This is a challenge that we spend a lot of time trying to solve here at CoreAVI but it is of course something that the industry has to step up and solve together. One possible approach is the adoption of open standards. We have seen this work very well in the hardware world with standard compute form factors such as COM-Express and VPX. The same approach can be applied in the safety related software domain. What I’m specifically referring to is the middle part of the software stack that sits between the hardware and the application. In an ideal world, we would like to provide a safe, open standards-based hardware abstraction layer that would allow applications to sit atop any hardware platform regardless of the underlying CPU or GPU architecture. This is the holy grail and is perhaps stretching the realms of possibility today. However, achieving this with one or two caveats is a definite reality.
The Impact of Vulkan® SC
At this point, I want to introduce Vulkan® SC, a safety critical derivation of the industry standard Vulkan® API defined through the Khronos consortium. The Vulkan driver provides a ‘thin’, high performance interface to the underlying compute elements – typically the GPU. This could be extended to support other elements such as NPUs. This driver exposes a standards-based API to the application. Working with other industry partners and Khronos, CoreAVI proposed Vulkan SC – a safety critical implementation that would leverage all the goodness of the Vulkan API but for use in functionally safe designs. Subsequently, this proposal resonated, and the Vulkan SC Working Group was formed with CoreAVI as the Chair. That was around two and a half years ago. Today, thanks to the commitment of the Working Group members, we are at the point where the Vulkan SC standard is about to get ratified. We should not underestimate the impact of this significant milestone. What does it mean? Well, I’ll refer you back to the challenge called out earlier – we now have a solution to one part of the problem – an open standards-based safety critical driver that enables applications to be efficiently ported across diverse hardware platforms whilst meeting the stringent safety certification requirements such as ISO 26262, DO-178C and IEC 61508. Scalability, reuse and safety – done!
As a footnote, the story gets even better. Using Vulkan SC as a foundational layer, CoreAVI has further extended this standards-based philosophy to include functionally safe libraries that sit directly on top to provide other popular APIs such as OpenGL® SC1 and OpenGL® SC2, video encode and decode (H.264 etc.), BLAS and FFT math functions and OpenVX™ for safe compute applications such as computer vision and neural networks.
As a result, with the ratification of the Vulkan SC standard and the complementary library offerings, I strongly believe that developers now have ‘port of choice’. They can build applications for both safe graphics and compute mass deployment that support not only today’s hardware platforms but that are also efficiently scalable to tomorrow’s implementations. This drives innovation, whilst significantly reducing development cost and schedules in support of a safer world.
