1. LedsystT Design Rules – Results and experiences 2006-06-15
Håkan Davidsson
SENI/Combitech AB

2. 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

3. 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

4. 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

5. Architecture Description Model
System in focus
Operational
Technical

6. 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

7. 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

8. Aspect and domain oriented descriptions

9. 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

10. 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

11. 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

12. 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

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

14. 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

15. The lifecycle - Design rules and Systems

16. Packaging design rules

17. 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.

18. 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

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

20. Design Rule candidates - example1
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

21. Questions?