1. Modularity, Upgradeability and Openness – How to meet Requirements in a Family of Systems Peter Henderson University of Southampton

2. September, 2007Peter Henderson, University of Southampton 2 Motivating Example This is a Roving Autonomous Vehicle. It accepts instructions in the form of a plan, which it then carries out autonomously. It is a fictional example.

3. September, 2007Peter Henderson, University of Southampton 3 Structural Architecture of RAV1.0 The Manager module is in charge. It instructs the Power module when movement is required. It instructs the Drive module when steering is required. It uses information from Sensor 1 to avoid collisions. It uses information from Sensor 2 to determine its own location. It uses the Comms module to communicate with home. Sensor 1Power CommsManager Sensor 2Drive

4. September, 2007Peter Henderson, University of Southampton 4 A note on Notation Using a shorthand for UML component diagrams The arrows can be read as “uses” Or as interfaces, supplied by one component to another Or as a place to address functional requirements Components may be hardware, software or a combination of both Components are potentially independently procurable CommsManager CommsManager

5. September, 2007Peter Henderson, University of Southampton 5 Supply of RAV1.0 There are 7 components here. The six modules and the platform As well as supplying the physical solutions (wheels, etc), the platform also provides the on-board networking and other infrastructural aspects. Each of the 7 components is potentially separately procurable. Colour here denotes supplier. Each component contains both hardware and software. Sensor 1Power CommsManager Sensor 2Drive

6. September, 2007Peter Henderson, University of Southampton 6 Mapping Requirements onto Architecture Requirement on RAV – The RAV will accept an instruction to move to a new location Induced Requirement on Comms module – The Comms module will store received messages until they are requested Induced Requirement on Manager Module – … etc. Induced Requirement on Infrastructure - … etc. Sensor 1Power CommsManager Sensor 2Drive

7. September, 2007Peter Henderson, University of Southampton 7 Upgrade to RAV1.2 Sensor 1Power CommsManager Sensor 2Drive Sensor 1Power CommsManager Sensor 2Drive Instuments RAV1.0RAV1.2

8. September, 2007Peter Henderson, University of Southampton 8 Upgrade to RAV2.0 Sensor 1Power CommsManager Sensor 2Drive Instuments RAV1.2 RAV2.0 Sensor 1Power CommsManager 1 Sensor 2 Drive Instuments Manager 2

9. September, 2007Peter Henderson, University of Southampton 9 Upgrade to RAV2.0 cont. RAV2.0 Sensor 1Power CommsManager 1 Sensor 2 Drive Instuments Manager 2 Comms Sensor 2Instuments Manager 3 RAV2.0 AV 1.0

10. September, 2007Peter Henderson, University of Southampton 10 Upgrade to RAV2.2 Comms Sensor 2Instuments Manager 3 RAV2.2 The autonomous part of the vehicle is now procured separately. Two alternative autonomous vehicles are ordered, from different suppliers The rest of the RAV architecture is opened for value-adding contributions, particularly to the Manager Application One Requirement to be met by RAV3.0 is collaboration within a group of RAVs AV 1.0

11. September, 2007Peter Henderson, University of Southampton 11 Upgrade to RAV3.0 Comms Sensor 2Instuments Manager 4 RAV3.0 One Requirement to be met by RAV3.0 is collaboration within a group of RAVs This will require at very least a much more elaborate Manager module It may not require changes to other components The ability of third-parties to supply value-addding Manager applications creates new business for platform suppliers This leads to a strong business case for Openness AV 1.0

12. September, 2007Peter Henderson, University of Southampton 12 Openness Comms Sensor 2Instuments Manager 4 RAV3.0 A modular architecture such as this may be Open in the sense that independent suppliers can supply replacement components, relying on the interface specifications Open Standards are needed to de-risk this dependence on interfaces In a specific application area (such as RAVs) it would be necessary to establish this Standards Body AV 1.0

13. September, 2007Peter Henderson, University of Southampton 13 Open Standards Body Comms Sensor 2Instuments Manager 4 RAV3.0 The RAV Standards Body would maintain an Architecture Specification which includes … description of the behaviour of each component … description of the the interfaces to each component … and description of the chatter across these interfaces … in evolving versions AV 1.0

14. September, 2007Peter Henderson, University of Southampton 14 Lessons from Open Source Many of the business benefits of Open Source can be realised in the more restricted domain of Open Systems In particular –New business models –Higher Quality –More Rapid Technology Roll Out

15. September, 2007Peter Henderson, University of Southampton 15 Open Source – New Business Models Indirect Sale Value models (from Eric Raymond) 1.Open Source maintains a market position for proprietary software 2.Open Source applications increase sales of specialised hardware 3.Open Source creates a market for support services 4.Open Source creates a market for accessories 5.Sell Open Source Futures 6.Sell the Brand by branding derivatives 7.Sell the Content

16. September, 2007Peter Henderson, University of Southampton 16 Open Source – Higher Quality Arises from greater attention to testing and debugging coming from larger developer community Plus some selection process that guarantees improvement as part of evolution

17. September, 2007Peter Henderson, University of Southampton 17 Open Source – Rapid Technology Roll Out Also arises from greater attention to product coming from larger developer community More options discovered/invented More options pursued Survival of the fittest

18. September, 2007Peter Henderson, University of Southampton 18 Structural Architecture of RAV1.0 alternative model (cf slide 3) The Manager module is in charge. It instructs the Power module when movement is required. It instructs the Drive module when steering is required. It uses information from Sensor 1 to avoid collisions. It uses information from Sensor 2 to determine its own location. It uses the Comms module to communicate with home. Infrastructure Sensor 1 Power CommsManager Sensor 2Drive