Why we need to think differently about the system context
No system exists in a vacuum. Therefore, an important task of the system architect is to define the context of the system. This is nothing new and has been practiced for decades. What is new is that it is no longer enough to estimate the context at the outset. Instead, modern systems must be able to deal with a context that can change significantly at runtime. This requires new approaches in development.
System boundary and context boundary
A system is always embedded in an environment. The system cannot be considered without this environment. This is the context, which includes both material things such as users, energy supply or ambient temperature, as well as immaterial things such as regulations or physical laws.
Our system generally has a clear boundary: the wheels belong to the "car" system, whereas the road does not. The road is part of the context, and a very relevant part at that. The problem for us is that the context does not stop somewhere: the moon is also part of the context, but hardly a relevant part. This is why the concept of the context boundary was traditionally introduced, which separates the relevant from the non-relevant part of the context.
The context of a vehicle
But this is where we encounter the problem with modern systems. Let's stay with a car. When it comes to developing a chassis, it is enough for us to set the minimum requirements for the context. The road must therefore have certain properties, such as condition, temperature, gradient, etc.
However, when we develop an autonomous vehicle, this is far from enough - at least today. Modern autonomous vehicles work with highly accurate maps. The context is therefore no longer a general road, but a specific road. The characteristics of this road are made up of the information stored in the map, which is combined with real-time data.
In addition, the relevant context is constantly changing. During development, only requirements were placed on the map material. The Overall context is defined at runtime when the map material is made available to the vehicle. The Relevant context changes continuously, depending on where the vehicle is, how it is moving and what information the vehicle sensors are providing.
The relevant context of modern systems changes continuously during operation
The traditional approach no longer works satisfactorily with such a system: the risk of making context-related errors is high and the effort involved would be enormous.
Is machine learning the answer?
To stay with autonomous vehicles: These typically use Machine Learningto create the control logic. In this way, we have - at least in the short term - got the context issue out of the way. However, it is already clear that this is not a practicable approach in the long term. After all, the data used to train the system must also be relevant in use. We need to continuously evaluate the context in order to be sure that the trained system is working in a relevant context. And it must also be possible to prove this: Both for compliance and for ethical reasons. For this reason, there are currently discussions about including training data for compliance purposes.
Context and requirements
Back to system development. The context is important, because we can only guarantee correct function if the context is right. For example, if the permissible ambient temperature for our car has been set at -15°C to 45°C, then there is no guarantee that it will start at -20°C.
The fulfillment of requirements can only be guaranteed in a valid context.
This is where it gets interesting for modern systems: as the context in operation is constantly changing, it may be that - depending on the context - certain requirements are no longer met. We want to prevent this at all costs.
Evaluate requirements and context at runtime
One possible way is to evaluate requirements and context at runtime. The I have already presented the theory behind this approach here under the name WRSPM before.
Specifically, one requirement could be: "The vehicle must be in a safe driving mode".
This requirement can be fulfilled in different ways. Specifically, here are two possibilities:
- Accurate maps AND autonomous mode ENABLES safe driving
- Any map material AND manual mode ENABLES safe driving
The system can now to runtime continuously evaluate the requirements. If suddenly - due to a context change - the requirement is no longer fulfilled, another constellation must be found at runtime to fulfill the requirement. Specifically, the system can give control to the driver if it leaves the area of the exact map material.
Conclusion
The System context is important, we have always known that. But traditionally this was defined and refined during development and was then constant at runtime. This has to change in order to be able to operate complex systems in a huge environment. And that means that the systems will take care of themselves at runtime to ensure that the important requirements are implemented.
