Common sense should tell us that rushing safety engineering processes, building with brand new technology that regulators are still wrapping their heads around, and generating an ROI on aircraft with historical 30-yr production lifecycles, isn’t going to work. As much as we all would enjoy experiencing the Jetsons, there is no doubt that the confidence of consumers that the vehicles are safe is a must before this market takes off.
But assuming stakeholders are committing enough resources and willing to be patient, what will it really take to get a flying car in our driveway? As mentioned in part one, while I may reference “flying car,” there will be various types of aircrafts deployed in the future including truly autonomous as well as those piloted by humans.
In part one of the two-part series, I detailed the importance of building safety nets and adopting to dynamic architecture in systems. Both are hot topics in this space but allow aircrafts to land safely after unpredictable scenarios. I also detailed the adoption of AI. The use of model driven system control and hazard analysis is fundamentally needed to achieve level 5 autonomy safely and affordable. That said, there are hundreds of nuanced artificial neural networks all with tradeoffs.
Here are additional technologies and design approaches industry stakeholders need to abide by to gain confidence and trust in level 5 autonomous systems to the comparable with the airliners we know of and have faith in today.
Validation with Confidence
As a software platform supplier, we don’t always get see how our customers, and customer’s customers use our software, especially when it comes to system level safety analysis. One of the more inspirational and reassuring moments I experienced, was working with a tier 1 automotive supplier who graciously gave me a walkthrough of how our software is referenced in safety system analysis. The foundation of their analysis is a model that maps passengers’ relationships with the vehicle interfaces and traces all the features of the vehicle into functions that ultimately translate to software allocated on computer parts. These models are massive. The number of properties that characterize passenger and vehicle state and nodes that connect people to capabilities, the layers of dependencies of the capabilities inherited as well as interference and contention generated by these capabilities represent a level of complexity that reminds me of a J.A.R.V.I.S scene from Iron Man. And bear in mind that the models I viewed related to relatively simple features put into regular cars. These models would naturally become significantly more complex to capture the dynamics of an autonomous platforms. The big questions are a) what is sufficient and b) how do we know it is correct? As much as I was impressed with the comprehensiveness and intent of the models I witnessed with my customer, I knew there were lower levels of complexity that were not explored that would manifest potential hazards under certain conditions. I also knew the assumptions about the functionality they expect from our supplied components were consistent with our product claims, but not actually proven with a mathematical level of confidence. Which leads to a bigger question about how we certify systems even today.
New Era of Certification
I don’t see how system validation is possible with today’s complex systems where the stakeholders responsible for validation are lacking sufficient expertise in low level technical complexities such as kernel design and memory controllers which play critical roles in enforcing architectural properties. Component level suppliers are not typically involved in system validation activities. They are expected to develop their product according to rigorous documentation, coding, and testing processes. They are expected to provide the body of evidence that a process was correctly followed. However, legitimate concerns exist as to whether these large bodies of evidence are meaningful from the perspective of proving intended behavior of components are consistent with system integrators assumptions.
It looks like FAA’s recent work in the Overarching Properties (OP) certification approach acknowledges the concern that the current verification and validation certification process focused too much on a waterfall compliance to streamline certification costs. OP has drawn attention to the bigger picture and more meaning question on whether a system’s intended behavior is correctly realized by imposing stronger degrees of formalism in the description of systems and all of the products used to constitute the system in question. In my experience, a product like a real-time operating system (RTOS) never had to justify approval, it just needed to comply to development standards. The new OP position states “if the product possesses the properties of Intent, Correctness, and Acceptability, then the product is suitable for installation else (that is, it does not possess the three properties) it is not.” This sounds like a step in the right direction. However, a fair concern is the feasibility of formalizing intent without this becoming nebulous, as well as the imposition of exorbitant costs to an already notoriously costly process.
Are we there yet?
Ultimately, no, we are not. But are we half-way there yet? Maybe. A good indicator would be the publication of safety development standards for artificial neural networks and concrete guidelines for use of AI derived adaptive behavior. The ratification of FAA Overarching Properties is a must. I wouldn’t feel safe yet until suppliers are required to formalize intended behavior and assumptions of their components to serve as a pre-requisite for validation of system level behavior.
Will Keegan, CTO, Lynx Software Technologies
In his role as chief technical officer, Will Keegan leads the technology direction across all the Lynx product lines. He has been instrumental in the development of key security technologies within Lynx to broaden the reach of the existing products, with a focus on cyber-security, cryptography and virtualization. Will joined Lynx in 2011 as the director of security solutions, with responsibility for the LynxSecure product line. Prior to Lynx, he was a product developer at Objective Interface Systems, Inc., with responsibility for product engineering of real-time middleware and high assurance cryptographic network technologies. He holds a BS in Computer Science from University of Texas.
