LedsystT Design Rules – Results and experiences
2006-06-15
Håkan Davidsson
SENI/Combitech AB
[email protected]
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
1
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
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
2
LedsystT Main driver - flexibility
Developmental flexibility
Operational flexibility
Years/Months
Time
Changes
Minutes/Seconds
Technology changes,
New major requirements
New missions,
New organizations
System
Assembly
Change Architecture
Required
System
Change or
Action
Updated
capabilities
needed
Operational
changes
Operate/Maintain
Capability
Service
Assembly
Add/Update
System/Module/
Services
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
3
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
Sverige
xxx
0 km/hr
(fixed network)
Force with separate FHQ
Combat vehicle
Soldier
Recipient
Urban area
Order/request/reports
Streaming
video/response
National responsibility
OPIL/TK
10000 km
II
xxx
FHQ
O
H
0 km/hr
(fixedQ
network)
0 km/hr
(transportable/
fixed network)
0 km/hr
(transportable/
fixed network)
RDF
HQ
50 km
200 km
Technical System
Core
Units
70 km/hr
(mobile node)
(+)
200 km
Core functionality within:
•Security
•Manageability
FCP
50 km
Soldiers
Core
5 km/hr
units
70 km/hr
(mobile node)
Core
5 km
Architecture balances the provision of functions and information to users and locations
where activity has to be performed
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
4
Architecture Description Model
System in focus
Operational
Technical
Supports
Operational node
Connects through4
Operational node connection
Technical system node
Network
Provides4
*
Acts in4
Communicates through4
Performs4
Information exchange
3 Provides
Interface
Role
Uses/provides4
Is located in
Has information content4
Is responsible for4
Information
3 Processes
Provides, uses4
Acts in4
*
Uses, processes and produces4
Org unit
Is responsible for4
Activity
Technical system function 3 Produces/consumes Technical system
3 Supports
0..*
Can
* consist of4
Subunits4
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
5
Architecture is defined by three architecture levels
Overarching
(OA)
SwAF
15 years
FMLS 2010
Reference
(RA)
Link16
FMLS 2010 Tech
Air
C4ISR
Navy
C4ISR
Navy
Air
6 years
TA
TA
TA
TA
TA
TA
TA
TA
TA
TA
TA
TA
Target
(TA)
1- 2 years
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.
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
6
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 framework gives
guidelines on how to
elaborate architecture
descriptions
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
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
7
The design rules
describe detailed rules
to follow when
designing a system,
according to the
architecture
Aspect and domain oriented descriptions
FMLS 2010
OA
RA Aspect
RA Missions
RA
RA
RA Information
RA Information
RA Governance
RA Governance
RA Security
RA Security
RA Information System
RA Domain
RA Infrastructure
Design document
TA Technical
TA Operational
TA Mission
DTa
TA
TA
TA
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
8
Architecture descriptions and SwAF processes
SwAF HQ processes
Planning process
Production process
TA
TA Operational
• TA Corvette Vby
• TA NBC Platoon
• TA BGHQ
TA
Mission process
TA Technical
• TA Corvette Vby
• TA PDA
• TA ASC890
• TA BGHQ
RA
RA Aspect
• RA Domain
• RA Information
• RA Information system
• RA Infrastructure
• RA Security
• RA overnance
OA
OA
AF
OA Sub level
• OA FMLS
• OA ERP
OA Top level
• OA SwAF
Framework
• SwAF
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
9
TA
TA Mission
• TA Kosovo
• TA Civil
RA
RA Mission
• RA RDF
• RA Cimic
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
ID
Principle Name
Usage
Id#
Name
M/O
Principle
statement:
Text
Motivation:
Text
Implication:
Operational:
Text
Information:
Text
Information system:
Text
Infrastructure:
Text
Governance:
Text
Security:
Text
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
10
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
Standardize solutions
to design problems
within NBD
Gives value to
the re-user
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
11
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
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
12
Design rules – where and how do they fit
Capability
needs
NBF
properties
Generic
rqmts
System
rqmts
Design rules
Architecture
Design
Architecture
principles
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
13
Principle of structuring Design Rules
Shall give relations and consistency
High Level Design Rule
Area 1
Area 2
• between solutions in defined problem
areas
Area 3
• to other high level design rules
Generates
DR
DR
Top-down
DR
Top/Bottom-Down/up
Must be connected!
DR
Requirements
Harvested Design Rules
Bottom-up
Structure
Design
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
14
The lifecycle - Design rules and Systems
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
15
Packaging design rules
Breakdown of
problem domains
TDR
DRP
DRP
DRP
DRP
DRP
DR
DR
Reusable solutions within
each problem domain.
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
16
VoV of Design Rules
Methods
• Appraisal
– 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.
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
17
Design Rule approval strategies A-F
and their criteria
D: Realization test
in a test system e.g.
prototype, demo
A: Inspection of a
solitary Design Rule
C: Inspection of
design where the
TDR is implemented
B: Inspection of Use
by Requirements
E: Successfully
used in N similar
deployed systems
F: Used in M
different types of
deployed systems
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
18
High Level Design Rules
•
•
•
•
•
•
•
Flexibility
Mobility aspects of flexibility
Scalability
Interoperability
Legacy integration
Risk management
Security aspects of
– Information
– Flexibility
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
19
Design Rule candidates - example
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Advanced Routing
Multipeer Communications over Heterogeneous Networks
One Common Convergence Layer
Information Prediction
Data Incest Prevention
24 Routing, Hosting, Traffic separation
25 One common IP network
26 Prioritization
Interface requirements of communication
27 infrastructure
Radio and Communication Silence
Service Location Independency
Caching (geographical information)
Creation of Role Based Situation Pictures
Notification
QoS
Representation of Ad-hoc Organizations
Security in SOA
Security mechanism:
Security mechanism:
Security mechanism:
Security mechanism:
Security mechanism:
Security Policy Principles
Service metadata
Situation Adaptation
Static and Dynamic Registries
28
29
30 Group handling
31
32
33
34
35
36
Inheritance
Configuration
Installation
Monitor security
37
38 System & Service unique identification
39
Risk Management adaptable design of the FMLS2010
40 system
41
How to choose which security functions for specific IT
42 platforms
43 System of Systems Micro Kernel
44 Security Approach
45 Flexibility
46 Interoperability
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
20
Questions?
Designpartner
SAAB ERICSSON NBD INNOVATION
2006-06-15
21