Title: Systems Engineering
1Systems 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
2What 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
3What 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
4Problems 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
5Software 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
6Emergent 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
7Examples of emergent properties
- The overall shape and size of a physical system
- This depends on the composition of components.
- The reliability of the system
- 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.
8Types 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.
9System 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
10Reliability 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
11The 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?
12System 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
13Functional system components
- Sensor components
- Actuator components
- Computation components
- Communication components
- Co-ordination components
- Interface components
- All are now usually software controlled
14Hierarchies of Systems
15Intruder alarm system
16Component types in alarm system
- Sensor
- Movement sensor, Door sensor
- Actuator
- Siren
- Communication
- Telephone caller
- Coordination
- Alarm controller
- Interface
- Voice synthesizer
17ATC system architecture
18Inter-disciplinary involvement
19Embedded systems
- Computing systems are everywhere
- Most of us think of desktop computers
- PCs
- Laptops
- Mainframes
- Servers
- But theres another type of computing system
- Far more common...
20Embedded 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.
21A 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 Photoc
opiers Point-of-sale systems Portable video
games Printers Satellite phones Scanners Smart
ovens/dishwashers Speech recognizers Stereo
systems Teleconferencing systems Televisions Tempe
rature controllers Theft tracking systems TV
set-top boxes VCRs, DVD players Video game
consoles Video phones Washers and dryers
- And the list goes on and on
22Some common characteristics of embedded systems
- Single-functioned
- Executes a single program, repeatedly
- Tightly-constrained
- Low cost, low power, small, fast, etc.
- Reactive and real-time
- Continually reacts to changes in the systems
environment - Must compute certain results in real-time without
delay
23An embedded system example -- a digital camera
- Single-functioned -- always a digital camera
- Tightly-constrained -- Low cost, low power,
small, fast - Reactive and real-time -- only to a small extent
24Design challenge optimizing design metrics
- Obvious design goal
- Construct an implementation with desired
functionality - Key design challenge
- Simultaneously optimize numerous design metrics
- Design metric
- A measurable feature of a systems
implementation - Optimizing design metrics is a key challenge
25Design 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
26Design 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
27Design metric competition -- improving one may
worsen others
- 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
Hardware
Software
28Robotic System
Video
29Robotic 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.
30Robotic System Application
31Electric SCADA System
32Web-Based Software System
http//people.csail.mit.edu/hal/mobile-apps-spring
-08/videos/flare.mpg
33Key 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
34Conclusion
- 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 others
strengths and actively rather than reluctantly
cooperate in the systems engineering process