Some of my colleagues have recently been talking to an automotive manufacturer who is starting to build self-flying cars. The “urban mobility” segment is experiencing significant investment and leading manufacturers are claiming vehicles will be open to the public as early as 2023.
After holding discussions with pioneering firms that are pursuing the vision of the flying car, I have started to contemplate how these two industries will come together. Somehow air vehicles need to be built in the volumes and price points of ground vehicles, while constructed and tested to the same level of quality and rigor as airliners. That’s a lot to think about.
The idea of bullish tech investors rushing to realize personal air vehicle transport, at the production volumes of automobiles, under the regulations of the avionics industry feels like a stalemate.
To be clear, while I reference a “flying car” above, which obviously implies more of a commercial application, the battlefield is changing. There will be a diverse range of craft deployed in future including pure autonomous craft and others containing pilots. These systems will be connected with aircraft controlling drones and collaborating with troops on the ground and sea. But how do we get to that future?
Having ground zero engineering experience in developing and certifying software components for aircraft and automotive LRUs (Line Replaceable Unit) and ECUs (electronic control unit) (like flight control, engine control, cockpit display, ADAS, and most recently autonomous flight control) here are technologies and design approaches industry stakeholders need to embrace, master, and hold accountable to gain parity in the confidence of airworthiness for level 5 autonomous systems to the comparable with the airliners we trust today.
System Architecture – building safety nets
Having worked on several level 4 autonomy platforms, a recurring design challenge emerges when constructing safety nets to mitigate single points of failure for critical functions. The preferred choice of achieving redundancy is to replicate functions on independent sets of hardware (usually three sets to implement triple-mode redundancy.)
Putting aside the size weight, power and budget issues, simply replicating functions on independent hardware components still leaves room for common mode failures - where redundant hardware components fail together from internal design issues. For this reason, safety authorities expect to see redundancy implemented with dissimilar hardware. However, this becomes even more challenging when considering the microprocessor ecosystem shares commonality of subsystems like memory controllers. Assuming architects are successful in finding dissimilar parts, these parts also need to be qualified to meet environmental requirements and comply with safety development standards. If all those hardware conditions are met, then another incredibly costly challenge emerges. The company must source software platforms compliant to safety standards on dissimilar hardware that sufficiently manage emerging multicore timing and integrity issues.
Lastly, product manufacturers pursuing such designs are left with limited concrete guidance on what is the sufficient level of redundancy required, especially traversing from coarse grain system design to fine grain sub-system/component design. The uncertainty from an architect’s design choices and lack of clarity from authorities presents enough risk to cancel most endeavors.
System Architecture – Adopting Dynamic Architectures
The adoption of dynamic architectures has become a hot debate in the safety system community. Safety systems are traditionally built around static methods. The ultimate goal of safety system analysis is to fully examine a system’s behavior such that that all aspects of behavior is predictable and guaranteed to operate in a safe manner for a given environment.
Static systems lend well to analysis of system behavior, given the functionality and parameters to the system are all declared up front for human and automated static analysis. The idea of allowing fundamental properties of the system to change dynamically creates significant analysis challenges.
The big debate on adoption of dynamic capabilities is centered on the idea that a system can reconfigure its behavior in-flight to adapt to unpredictable scenarios. The concept of “limp home mode” is an excellent example of a capability that benefits greatly from dynamic architecture. This is where a major system failure has occurred (E.g. bird caught in propeller, or processor dies) and other parts of the system are smart enough to distribute necessary functions across available resources to achieve a sufficient level of functionality to protect the users and environment bystanders. As an example, if a processor in the ADAS ECU, the main processor in the infotainment system can be reallocated to support this processing. The passenger misses out on listening to the BBC World Service for the remainder of his journey, but he is able to land safely. I am aware of several traditional aerospace and defense companies starting to explore these types of architectures and coupled with some interesting advances that the semiconductor companies are making in next generation automotive platforms in terms of strengthened security and isolation of processes, my sense is that this is the approach that will win out in the longer term.
AI Adoption
The use of AI seems like forgone conclusion for Level 5 autonomy. With no human oversight, computers will have to determine how to control machines at many levels - basic route planning and propulsion is a given, fuel consumption optimization, multi-dimension hazard detection and avoidance, and then internal hazard detection for supporting features like “limp home mode.” The permutations of variables that can affect the state of system are clearly overwhelming; 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.
Over a thirty year period, safety standards have only been able to support the use of a few programming languages (C,C++,Ada) with sufficient knowledge and provide concrete guidance of use accompanied by a mature ecosystem tool suppliers. It’s safe to assume, therefore, that the vast world of neural networks needs to be paired down, unpacked and guided according the goals and principles casted in DO-178C DAL A and ISO26262 ASIL-D. This is not news to the safety community and some excellent coverage on the problem space has been documented in in this FAA publication TC-16/4’ “Verification of Adaptive Systems.” However clear guidelines of use and development process standards have yet to surface for artificial neural networks (ANN).
In part two of this two-part series, we’ll investigate additional technologies needed in order to have a future made up of a diverse range of aircrafts. I’ll be outlining how close we are to cities filled with manned and autonomous aircrafts and more.
