LedsystT Design Rules – Results and experiences 2006-06-15 Håkan Davidsson SENI/Combitech AB hakan.davidsson@combitech.se

LedsystT – Four main areas M Methods for development of FMLS 2010 Technical System A Description Frameworks, Architecture and Design for FMLS 2010 Technical System B Technical Design Rules to be applied when developing and deploying FMLS 2010 Technical System D Design to prove or make plausible that Methods, Framework and Technical Design Rules are valid and usable

LedsystT Main driver - flexibility Developmental flexibility Operational flexibility Years/Months Minutes/Seconds Time Updated Updated Operational Operational Technology changes, New missions, Changes capabilities capabilities changes changes New major requirements New organizations Operate/Maintain Operate/Maintain needed needed Capability Capability Service Service System System Assembly Assembly Assembly Assembly Add/Update Change Architecture A slide that describes different aspects of flexibility from a time perspective. Main motives for flexibility are a rapidly changing and highly complex operational environment and need for a shorter technical development cycles A number of system changes are illustrated as a mean to achieve flexibility from the: Operational needs (fast cycle) Technical development perspective (somewhat slower cycle – but needs to be faster in the future) From vision The enabler for being able to introduce new functionality in terms of new services is the loose coupling between service implementations and between the service implementation and the infrastructure. In order for new functionality to be incorporated it has to be developed according to a given collection of Design Rules. A more long term perspective on the continuously evolving system is the change of more fundamental parts such as the architecture. Although architectural decisions are made in a long term perspective they may have to be revised and reformulated. In order to be able to do such revisions and reformulations without a complete redesign of the complete FMLS 2010 system the consequences and motivations for the original decision have to be clear. This means that the original decisions and their motivations and consequences together with considered alternatives must be understood and documented. The documentation of these decisions is part of the FMLS Enabling System and manifested in terms of Design rules. System/Module/ Services Required System Change or Action

The Architecture defines abilities for Operational Systems and Technical Systems FMLS 2010 architectural demands : Flexibility Availability and Reliability Mobility Usability Interoperability Security Cost effectiveness Operational System Combat vehicle Soldier Recipient Urban area Order/request/reports Streaming video/response OPIL/TK RDF HQ 10000 km 200 km 50 km 5 km 0 km/hr (fixed network) (transportable/ fixed network) Units 70 km/hr (mobile node) units Sverige II FCP Soldiers 5 km/hr FHQ xxx Force with separate FHQ (+) National responsibility OHQ Technical System Core Core functionality within: Security Manageability Architecture balances the provision of functions and information to users and locations where activity has to be performed

Architecture Description Model System in focus Operational Technical

Architecture is defined by three architecture levels Overarching (OA) SwAF FMLS 2010 15 years FMLS 2010 Tech Navy C4ISR Navy Reference (RA) Link16 Air C4ISR Air 6 years TA TA TA TA The three architecture types have different scope, time span and level of detail. They are hierarchically dependant on each other, where OA is the highest level, has the widest scope, longest time span and the least detail. RA is depending on OA and TA is depending on RA. TA is the lowest level with the most narrow scope, the shortest time span and the most detail. TA TA TA TA TA TA TA TA Target (TA) 1- 2 years

Architecture descriptions Overarching Architecture Reference Architecture Target Architecture Framework Design Rules The overarching architecture describing principles and an overall description of the entire FMLS 2010 system. The reference architectures, describe general rules and patterns for developers and architects to use when creating deployable instances of a system. The target architecture, describes rules and patterns for developers to use when creating a specific system instance The framework gives guidelines on how to elaborate architecture descriptions The design rules describe detailed rules to follow when designing a system, according to the architecture

Aspect and domain oriented descriptions

Architecture descriptions and SwAF processes SwAF HQ processes Planning process Production process Mission process TA Operational TA Corvette Vby TA NBC Platoon TA BGHQ TA Technical TA Corvette Vby TA PDA TA ASC890 TA BGHQ TA Mission TA Kosovo TA Civil TA TA TA RA Mission RA RDF RA Cimic RA RA OA Sub level OA FMLS OA ERP OA RA Aspect RA Domain RA Information RA Information system RA Infrastructure RA Security RA overnance OA OA Top level OA SwAF AF Framework SwAF

Architecture principles Principles are the enduring underlying general rules which hold true across the architecture ~ 10 principles defined for OA level Principle statement and motivation in one or two sentences Implication described according to 4+2 architecture aspects

Design Rules - the definition A design rule is a solution to a problem in a specific context with the following characteristics: Belongs to a problem domain Packages knowledge in a reusable form Gives value to the re-user Standardize solutions to design problems within NBD

Design rule fundamentals A design rule shall be able to live without dependencies to the requirements that were the cause that it was created Design that is worth to be remembered so it can be re-used and transfer technology shall be documented in a specific system independent way as design rules

Design rules – where and how do they fit Capability needs NBF properties System rqmts Generic rqmts Design rules Architecture Design Architecture principles

Principle of structuring Design Rules Shall give relations and consistency between solutions in defined problem areas to other high level design rules High Level Design Rule Area 1 Area 2 Area 3 Generates Top-down DR DR DR Top/Bottom-Down/up Requirements Must be connected! DR Harvested Design Rules Bottom-up Structure Design

The lifecycle - Design rules and Systems

Packaging design rules

VoV of Design Rules Methods Appraisal Verification Some Design Rule has such an abstraction level that it is impossible to define quantitative results from verification, e.g. High Level Design Rules Verification A problem and a context A set of requirements1 A solution (architecture, design etc.) that also can use other design rules (associations according to the framework). The solutions shall be traceable to the problems Analysis with a clear motivation why the selected solution is used 1 Observe that a design rule never points on requirements, only vice versa.

Design Rule approval strategies A-F and their criteria A: Inspection of a solitary Design Rule B: Inspection of Use by Requirements C: Inspection of design where the TDR is implemented D: Realization test in a test system e.g. prototype, demo E: Successfully used in N similar deployed systems F: Used in M different types of deployed systems

High Level Design Rules Flexibility Mobility aspects of flexibility Scalability Interoperability Legacy integration Risk management Security aspects of Information

Design Rule candidates - example 1 Advanced Routing 2 Multipeer Communications over Heterogeneous Networks 3 One Common Convergence Layer 4 Information Prediction 5 Data Incest Prevention 6 7 Radio and Communication Silence 8 Service Location Independency 9 Caching (geographical information) 10 Creation of Role Based Situation Pictures 11 Notification 12 QoS 13 Representation of Ad-hoc Organizations 14 Security in SOA 15 Security mechanism: 16 17 18 19 20 Security Policy Principles 21 Service metadata 22 Situation Adaptation 23 Static and Dynamic Registries 24 Routing, Hosting, Traffic separation 25 One common IP network 26 Prioritization 27 Interface requirements of communication infrastructure 28 29 30 Group handling 31 32 Inheritance 33 Configuration 34 Installation 35 36 Monitor security 37 38 System & Service unique identification 39 40 Risk Management adaptable design of the FMLS2010 system 41 42 How to choose which security functions for specific IT platforms 43 System of Systems Micro Kernel 44 Security Approach 45 Flexibility 46 Interoperability

Questions?