Transcript Project management

Systems Engineering


Designing, implementing, deploying and
operating systems which include hardware,
software and people
Objectives
•
•
•
To explain why system software is affected by broader system
engineering issues
To introduce the concept of emergent system properties such as
reliability and security
To explain why the systems environment must be considered in
the system design process
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 1
What is a system?




A purposeful collection of inter-related
components working together towards some
common objective.
A system may include software, mechanical,
electrical and electronic hardware and be
operated by people.
System components are dependent on other
system components
The properties and behaviour of system
components are inextricably inter-mingled
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 2
What is a system?




A purposeful collection of inter-related
components working together towards some
common objective.
A system may include software, mechanical,
electrical and electronic hardware and be
operated by people.
System components are dependent on other
system components
The properties and behaviour of system
components are inextricably inter-mingled
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 3
Problems of systems engineering


Large systems are usually designed to solve
‘nasty’ problems
Systems engineering requires a great deal of
co-ordination across disciplines
•
•

Almost infinite possibilities for design trade-offs across
components
Mutual distrust and lack of understanding across engineering
disciplines
Systems must be designed to last many years in a
changing environment
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 4
Software and systems engineering

The proportion of software in systems is
increasing
•


Software-driven general purpose electronics is replacing
special-purpose systems
Problems of systems engineering are similar to
problems of software engineering
Software is (unfortunately) seen as a problem in
systems engineering
•
Many large system projects have been delayed because of
software problems
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 5
Emergent properties



Properties of the system as a whole rather than
properties that can be derived from the properties
of components
Emergent properties are a consequence of the
relationships between system components
They can therefore only be assessed and
measured once the components have been
integrated into a system
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 6
Examples of emergent properties

The overall shape and size of a physical system
•

The reliability of the system
•

This depends on the composition of components.
This depends on the reliability of system components and the
relationships between the components.
The usability of a system
•
This is a complex property which is not simply dependent on the
system hardware and software but also depends on the system
operators and the environment where it is used.
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 7
Types of emergent property


Functional properties
•
These appear when all the parts of a system work together to achieve
some objective
•
For example, a bicycle has the functional property of being a
transportation device once it has been assembled from its
components
Non-functional emergent properties
•
•
•
Examples are reliability, performance, safety, and security
These relate to the behaviour of the system in its operational
environment
They are often critical for computer-based systems as failure to
achieve some minimal defined level in these properties may make
the system unusable.
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 8
System reliability


Because of component inter-dependencies, faults
can be propagated through the system
System failures often occur because of unforeseen
inter-relationships between components
•

Honey-baked ham
It is probably impossible to anticipate all possible
component relationships
•
•
•
Hardware
Software
Operator
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 9
Reliability relationships



Hardware failure can generate spurious signals
that are outside the range of inputs expected by
the software
Software errors can cause alarms to be activated
which cause operator stress and lead to operator
errors
The environment in which a system is installed
can affect its reliability
•
E.g., placement of a system intended to operate at room
temperature near an air conditioner
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 10
The ‘shall-not’ properties


Properties such as performance and reliability can
be measured
However, some properties are properties that the
system should not exhibit
•
•

Safety - the system should not behave in an unsafe way
Security - the system should not permit unauthorised use
Measuring or assessing these properties is very
hard
•
How do you know you are safe or secure?
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 11
System architecture modelling




An architectural model presents an abstract view
of the sub-systems making up a system
May include major information flows between
sub-systems
Usually presented as a block diagram
May identify different types of functional
component in the model
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 12
Functional system components







Sensor components
Actuator components
Computation components
Communication components
Co-ordination components
Interface components
All are now usually software controlled
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 13
Hierarchies of Systems
Town
Street
Building
Heating
system
Power
system
Water
system
Security
system
Lighting
system
Waste
system
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 14
Intruder alarm system
Door
sensors
Movement
sensors
Alarm
contr oller
Siren
Voice
synthesizer
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
External
control centre
Telephone
caller
Slide 15
Component types in alarm system

Sensor
•

Actuator
•

Telephone caller
Coordination
•

Siren
Communication
•

Movement sensor, Door sensor
Alarm controller
Interface
•
Voice synthesizer
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 16
Radar
system
Position
processor
Aircraft
simulation
system
Transponder
system
Aircraft
comms.
Da ta comms.
system
Comms.
processor
Backup
position
processor
Telephone
system
Backup comms.
processor
ATC system
architecture
Flight plan
database
Weather map
system
Accounting
system
Controller
info. system
Controller
consoles
Activity logging
system
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 17
Inter-disciplinary involvement
Software
engineering
Electronic
engineering
Mechanical
engineering
Structural
engineering
ATC systems
engineering
User interface
design
Civil
engineering
Electrical
engineering
Architecture
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 18
Embedded systems


Computing systems are everywhere
Most of us think of “desktop” computers
•
•
•
•

PC’s
Laptops
Mainframes
Servers
But there’s another type of computing system
•
Far more common...
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 19
Embedded systems overview

Embedded computing systems
•
•
•
•
Computing systems embedded within
electronic devices
Hard to define. Nearly any computing system
other than a desktop computer
Billions of units produced yearly, versus
millions of desktop units
Perhaps 50 per household and per
automobile
Computers are in here...
and here...
and even here...
Lots more of these,
though they cost a lot
less each.
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 20
A “short list” of embedded
systems
Anti-lock brakes
Auto-focus cameras
Automatic teller machines
Automatic toll systems
Automatic transmission
Avionic systems
Battery chargers
Camcorders
Cell phones
Cell-phone base stations
Cordless phones
Cruise control
Curbside check-in systems
Digital cameras
Disk drives
Electronic card readers
Electronic instruments
Electronic toys/games
Factory control
Fax machines
Fingerprint identifiers
Home security systems
Life-support systems
Medical testing systems
Modems
MPEG decoders
Network cards
Network switches/routers
On-board navigation
Pagers
Photocopiers
Point-of-sale systems
Portable video games
Printers
Satellite phones
Scanners
Smart ovens/dishwashers
Speech recognizers
Stereo systems
Teleconferencing systems
Televisions
Temperature controllers
Theft tracking systems
TV set-top boxes
VCR’s, DVD players
Video game consoles
Video phones
Washers and dryers
And the list goes on and on
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 21
Some common characteristics of
embedded systems

Single-functioned
•

Tightly-constrained
•

Executes a single program, repeatedly
Low cost, low power, small, fast, etc.
Reactive and real-time
•
•
Continually reacts to changes in the system’s environment
Must compute certain results in real-time without delay
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 22
An embedded system example -a digital camera
Digital camera chip
CCD
A2D
CCD preprocessor
Pixel coprocessor
D2A
lens
JPEG codec
Microcontroller
Multiplier/Accum
DMA controller
Memory controller
•
•
•
Display ctrl
ISA bus interface
UART
LCD ctrl
Single-functioned -- always a digital camera
Tightly-constrained -- Low cost, low power, small, fast
Reactive and real-time -- only to a small extent
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 23
Design challenge – optimizing
design metrics

Obvious design goal:
•

Key design challenge:
•

Construct an implementation with desired functionality
Simultaneously optimize numerous design metrics
Design metric
•
•
A measurable feature of a system’s implementation
Optimizing design metrics is a key challenge
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 24
Design challenge – optimizing
design metrics

Common metrics
•
Unit cost: the monetary cost of manufacturing each copy of the
system, excluding NRE cost
•
NRE cost (Non-Recurring Engineering cost): The one-time
monetary cost of designing the system
•
•
•
•
Size: the physical space required by the system
Performance: the execution time or throughput of the system
Power: the amount of power consumed by the system
Flexibility: the ability to change the functionality of the system
without incurring heavy NRE cost
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 25
Design challenge – optimizing
design metrics

Common metrics (continued)
•
Time-to-prototype: the time needed to build a working version of the
system
•
Time-to-market: the time required to develop a system to the point
that it can be released and sold to customers
•
Maintainability: the ability to modify the system after its initial
release
•
Correctness, safety, many more
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 26
improving one may worsen
others

Power
Performance
Size
NRE cost
CCD
Digital camera chip
A2D
CCD preprocessor
Pixel coprocessor
D2A
Expertise with both software and
hardware is needed to optimize
design metrics
•
Not just a hardware or
software expert, as is common
•
A designer must be
comfortable with various
technologies in order to choose
the best for a given application
and constraints
lens
JPEG codec
Microcontroller
Multiplier/Accum
DMA controller
Memory controller
Display ctrl
ISA bus interface
UART
©Sommerville 2000, Medvidovic 2006, Mejia 2009
LCD ctrl
Hardware
Software
Systems Engineering
Slide 27
27
Robotic System
Módem Bluetooth
Cámara de visión
BlueSMiRF (WRL-00582)
(pan-and-tilt)
Video
Proxímetro IR
Unidad inercial
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 28
Robotic System
•
Mecanica + Control + Computacion
– Ingeniería de reversa (servomecanismos, controlador, programación)
– Mecánicas (cabeza, tobillos), comunicación inalámbrica, hardware para control,
– Sistema de programación, interfaz bidireccional para los servos…
• Percepción
– Sensores: Visión, Infrarrojos, Unidad Inercial
– Reconstrucción 3D Monocular
• SLAM Visual
– Odometría visual, Navegación Inercial (IMU), SLAM Visual, etc.
• Obtención de Modelos y Desarrollo de Simulador
– Geométrico, Cinemático, Dinámico
• Control Cinemático y Dinámico
– Control articular, control cinemático, control dinámico (ZMP, FRI)
• Aplicaciones
– Reconocer pelota, Evitar y reconocer obstáculos y marcas, Caminar hacia la pelota,
conducir la pelota, Penalties (tirar y parar), coordinacion con otros robots, Pruebas
RoboCup, Futbolistas.
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 29
Robotic System Application
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 30
Electric SCADA System
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 31
Web-Based Software System
http://people.csail.mit.edu/hal/mobile-apps-spring-08/videos/flare.mpg
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 32
Key points




System engineering involves input from a range of
disciplines
Emergent properties are properties that are characteristic
of the system as a whole and not its component parts
System architectural models show major sub-systems and
inter-connections. They are usually described using block
diagrams
System component types are sensor, actuator,
computation, co-ordination, communication and interface
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 33
Conclusion



Systems engineering is hard! There will never be
an easy answer to the problems of complex
system development
Software engineers do not have all the answers
but may be better at taking a systems
viewpoint
Disciplines need to recognise each other’s
strengths and actively rather than reluctantly
cooperate in the systems engineering process
©Sommerville 2000, Medvidovic 2006, Mejia 2009
Systems Engineering
Slide 34