PowerPoint Show

Download Report

Transcript PowerPoint Show

Ship System 2000,
a Stable Architecture under
Continuous Evolution
Björn Källberg and Rei Stråhle,
© SaabTech Systems AB, Sweden
(formerly CelsiusTech Systems,
before that: NobelTech Systems,
before that: Bofors Electronics,
before that: Philips Elektronikindustrier)
SIGAda 2001, Bloomington
Our Platforms and Track Record
SIGAda 2001, Bloomington
2
Coastal Corvette Göteborg live
3
Performance Examples
• Ship more stable than primitive rock
• Incorrect symbol shown in 0.3 sec is a
category 1 fault (which prevents delivery)
• Operator response time is 10 sec from detection of
missile(s) until own ship might be hit
• Safety critical

• System is different
• Many common component technologies can not
directly be applied
4
What is an architecture?
To create a logical sea!
logical view
physical view
cpu 1
cpu 2
LAN with BS2000
cpu n
5
Göteborg class
6
Software Architecture
•
•
•
•
•
•
•
•
Layered structure
Unit of distribution: Program
Location independent
Asynchronous messages
Parametrised components
MMI definition language
COTS Operating system
Ada (and some C, C++)
7
Product Line Management
SS2000 product line
Dev proj 1.
Dev proj 2.
Dev proj 3.
8
The Dual Life Cycle
The product line
or
the System Family
The
development
projects
9
Organisation then
Product line, Component development
requirements
spr:s
Csc:s
corrections
Development projects
Requirements
MMI-development
Integration
Testing
example: 8000 test cases.
15 man, 2 months
10
Organisation now
Product line, Component development, System backbone
(Customer) project
(Customer) project
(Customer) project
Requirements
Requirements
11
Challenges
•
•
•
•
•
•
•
•
Documentation
Dead code
Compartmentalisation
Error corrections and releases
Late system testing
Parametrisation
Complexity increase
Not a trivial assembling process
12
Dead Code
Reuse is not always appreciated by the customer
• Different shapes of not required code
–
–
–
–
–
Extra functionality that can be used
Functionality which can not be used
Code that executes, without any extra functionality
Code that is part of the system, but does not execute
Code that is removed before loading
• Disadvantages
–
–
–
–
Learning is difficult, risk of misuse
Performance is not optimal
Code may be excessively large
Maintenance problem
13
Layered Structure
Application interfaces
•
•
•
•
Controlled
Stable
Documented
Well known
WCS, Weapons and sensors
C3, Command management system
MMI, Man machine interface
Base system, application support
Operating system, distributed system
Base for reuse
This part is OS dependent
SIGAda 2001, Bloomington
14
Component Organisation
sensors
and weapons
C3
MMI
base
system
twsm twtr
enco guas guco gula gupa raa6 rasm shbo
brpo dias diir dila dipl dira disu
trut velo visi vsbx xtco
pred rege resu sacc sati sddi sira syth
naai nade nase ospo ossi patt piut
hist inpt lora lsnh mano matr
atdi ausu corr cout crow cryp ecsc ecsd
movi ppma rrin rrsc sedt sort surf surk
haco keha kema loin maha meha mit
acco alha apsi coob ctpi foma gcfu grap
syco syla syle sypa taco teha tiha tipr
opsy osfu ovpi posx srma ssif
evha evhx evpr fddi fise ipco joco jocs
adin adty anco baty coco daco dbai
ditr
ditv
tare tarp tipo
pldi plma
trdi
envi gade gaex gpos gpsi
tran tvco uitx vico wima
mmif mmiw pico bsco
gren grma grpr
stan
math nosu nosi
dbar dite dram
unchanged
smaller modifications
new / large modifications
removed
15
All programs in one pool
P1
P4
P2
P3
Ada
program
IPCO
P6
P5
16
Ada Component Structure (static)
a component is a set of
Ada packages
New component
Library component
Library component
17
Ada Program Structure
Program 2
A message is always
 Within a component
 Between programs
Program 1
LAN messages
SIGAda 2001, Bloomington
18
MMI Architecture
Operator
General MMI
program
Distributed MMI
interface database
P1
P2
P..
SIGAda 2001, Bloomington
Pn
Application
programs
19
Not an easy integration process
Blocks may be simple individually, but it takes a
considerable skill and time to build a large system
•
•
•
•
•
Parameter settings
Program allocation
Performance estimation
Complicated systems
Testing
20
Parametrisation
• Large number of parameters:
–
–
–
–
Parameterisation is used to adapt functionality
Versions not used
Also to set capacity, performance trimming
In place of understanding requirement,
deferring decisions
• Integration is difficult
21
Release Handling
P1
P2
P3
Release
• Error corrections can not be made directly
• Releases must be synchronised
• Working components may be changed
22
Complexity Increase
• Assume: Total complexity ~ product of component complexity
12
Complexity
10
8
CSC 1
CSC 2
CSC 3
CSC4
6
4
2
0
Proj 1
Proj 2
Proj 3
Product
Complexity: 200
70
400
7 200
SIGAda 2001, Bloomington
23
Development Environment
• Ada development
– Then: Rational hardware, Rational compilers
– Now: PC and Unix based; Aonix, OC Systems, ACT
• Documentation
–
–
–
–
Then: VAX/VMS,
Now: Windows NT, RS6000 Aix,
Exco editor (hierarchy and links)
MS Word
• C-code
– VAX/VMS and target
– different compilers
– PC and Unix
24
Education
• Since 1986 we have had >800 students in >120 courses
(incl. basic Ada training, Ada95 & application)
• Only own employees or from company partners
• Fundamental training in BaseSystem part of
ShipSystem starts with Error Handling, InterProgram
Comm, Tactical Config, Parametrisation and MMI
Programming
• Mandatory to follow Application Interface Standards
• Ada Quality & Style is recommended
• Deprogramming of C/C++ programmers is essential
25
We have succeeded.
Degree of reuse is high.
New
Modified
Unchanged
Similar Ships
Other ships
Other systems
SIGAda 2001, Bloomington
26
Summary
• The cost is high
• A product line development is not easy
– Software is different from hardware
– It is not a production process, it is a development
process
• The difficulties can be overcome
– with hard work
• The result can be very good
– but the domain must be limited
• Stable architecture from start of new project
27
Question time...
SIGAda 2001, Bloomington
28