Robotics Middleware - Composition of Subsystems

Composition of Subsystems

How to optimally compose subsystems into a larger system is the core activity of system developers, but is remains more of an art than of a science. The major challenge is to develop subsystems that are stable on their own, while still very willing to be part of a larger system. There are four different ways of composing software components:

• linking object classes by providing explicit references to each other:
• composing object classes without them knowing about each other
• composing components
• composing software services:

A composed system is stable if it can be used without the user having to know that it is a composed system in itself. Examples of commonly used compositions that are not stable are:

• Simulink blocks in feedback controllers: one often has to introduce explicit delay blocks; one cannot predict the overall performance on the basis of the performance of the individual blocks.
• Realtime aspects at the system level: only one of the components can really have the highest priority; schedulability of the activities in all components becomes exponentially harder to analyse, let alone to guarantee, when the number of components grows; IPC deadlocks become more likely, and more difficult to trace; formal verification becomes more difficult, since jitter and latency deteriorate in less predictable ways, compromising the ideal, abstract model of states with atomic and infinitely fast transitions and condition checks.
• Adding sensor processing or control blocks to a control loop: each new sensor can bring with it a device driver that requires a different sampling frequency, that provides a different spatial resolution, …