1) Context arising from the industry evolution and consequent need for standardisation and associated trusted third parties.
The evolution of the last decades for industries have seen a general movement of original vertical integration of the key technologies and competences inside the companies, to a world of
« horizontal integration » where each layer of an architecture can rely on a few world champions or on many smaller specialised actors.
The party delivering the final product to the end-customer has become an integrator that has to take care of the performance of the end product and take responsibility for it.
At the same time, this integrator has to make difficult choices on subsystems that can not be developped inhouse anymore, and that are in the hands of actors who have grown powerful on the market in the meantime.
Let’s take some examples :
In the PC and smartphone world, we see the continuation of the Apple vertically integrated model (hardware, operating system, applications), in front of the mainstream offers with Windows and Android where the responsibility of the performance is unclear between the hardware, the software and the service providers. With these products, nobody is completely responsible when the customer is frustrated, and he is invited to take care of his product by himself (for example anti- virus, parental control, etc). Only premium actors such as HTC, LG and Samsung claim to help the customer as far as they can.
As people have become aware and accustomed of the suboptimal performance and reliability of these consumer electronics products (that more or less justifies the premium when you buy Apple), this kind of situation is not acceptable at all between industry, or with products directly impacting customer safety.
However, the general movement of the industry, pushed by the digitization, connectivity and open markets is going horizontal anyway.
There is a strong need to build and maintain standards on the market to help industries go forward in the same direction (for example HDMI, USB V3, Sdcards), build a sufficient confidence level they can rely on to secure their investments.
As we can sometimes hear, « technology has become a facility », meaning that it can be purchased externally anytime, and that today’s knowledge relies evermore on smart assembling of external bricks.
The final integrators facing the customer market find it difficult to buy to near-monopolistic actors (example : fuel injection systems for automotive) while fighting to keep costs at a level where they can still make a profit.
This is one of the reasons of automotive standardisation initiatives such as AUTOSAR: an open architecture is supposed to avoid supplier-proprietary deadlocks in the system.
When the standard is in place, new actors can emerge that are not well-known, who have relied on the standardisation framework to develop their solutions. The challenge for integrators is then to be able to use these new purchasing opportunities, without bearing a major risk of quality or delay.
Once a standard is defined, approved and applied on the market, there is defintely a need for trusted third parties, able to certify the compliance to the standard, to validate a performance claim of the product, etc.
This is beneficial both for the suppliers (especially the new ones) who can use it to build trust with the buyers, and for the buyers, who can hope to benefit from new market opportunities with an acceptable risk.
The more tension there is on costs and delays, the more value in these independant upfront evaluations, that could become a prerequisite for suppliers to bid.
2) Current use cases with autonomous systems
Providers of these systems (autonomous vehicle, flexible industrial robot) have to manage a big additionnal risk : not only do they have to bear the risk of a highly complex system, possibly impacting human safety, but they also have to manage the interaction between the system and the human « component » inside and outside of the system.
As an example :
- A driver sets his car to autonomous mode, and later gets back to driving himself, on his own
initiative or because of a requirement of the system. The human component is inside the
system.
- An autonomous vehicle is taking into account a man driven car, a bicycle and a pedestrian.
The human component is external to the system.
This analysis leads to an enlarged perimeter for standardisation :
- High level behaviour rules of autonomous systems in a given field should be standardised and could be subject to homologation by institutions. This is necessary to protect manufacturers in terms of liability, and to help customers accept the introduction of systems by understanding and predict their behaviour to a certain extent
- Traceability requirements for legal purposes (« black box ») : the process under which accidents will be investigated will have to be unified. Legal teams having to understand a case will have to get knowledge of the context of the events, the behaviour of each party, and the origination of this behaviour : did the software comply with the standard rules, was there a malfunction in software or hardware, was there a misinsterpretation of sensor data, what was the overall timing, what were the human interventions, etc. It is clear that working on raw data won’t make sense. Data will have to be logged and structured with common rules, maybe using dedicated tools to be able to exploit them
- Technical standards for architectures, interfaces, processes : like for all complex systems relying on an industrial ecosystem, standards are necessary for the ecosystem to be grown through the investments of parties trusting the standard, and providing competition on each layer of the architecture.