Relevant Tools, Standards,

and/or Engineering Constraints

EMBEDDED SYSTEMS
Learning Objectives

 Understand the system requirements, architecture and allocation

 Describe the architecture diagram
 Identify the technical requirement for devices of an embedded system
 Recognize the constraints affecting the design of the embedded
system
 System Requirements, Architecture, and
Allocation

 When specifying a complex system, many teams first create a system

requirements specification, abbreviated SyRS.
(see http://www.iso.org/iso/catalogue_detail.htm?csnumber=45171)
 The SyRS describes the capabilities of the system as a whole, including
capabilities that could be provided by hardware components, software
components, and/or humans.
 It also describes all of the inputs and outputs associated with the system.
 In addition to functionality, the SyRS should specify the critical performance,
safety, and other quality attribute requirements for the product.
 System Requirements, Architecture, and
Allocation

 Requirements analysis of a complex system is tightly intertwined with the

system’s architecture. Requirements thinking and design thinking become
more commingled in real-time systems than in other types of software
projects.
 The architecture represents the top level of design, often depicted by using
simple box-and-arrow diagrams. A system’s architecture consists of three
elements:
 Components of the system, where a component could be a software object or
module, a physical device, or a person
 Externally visible properties of the components
 Connections (interfaces) between the system components
 System Requirements, Architecture, and
Allocation

 The architecture is developed in a top-down, iterative fashion. The person who

takes the lead role in this type of analysis typically is a systems analyst,
requirements engineer, systems engineer, or systems architect with a strong
technical background.
 The analyst partitions the system into appropriate software and hardware
subsystems and components that will accommodate all of the inputs and
produce the outputs.
 Certain system requirements might turn directly into software requirements if
software is deemed to be the correct medium for providing a certain capability.
 In other cases, the analyst will decompose individual system requirements into
numerous derived software, hardware, and/or manual requirements to be
performed by humans.
Figure 1. System requirements are decomposed into software, hardware, and manual
requirements, then allocated to appropriate components.
 System Requirements, Architecture, and
Allocation
 It’s a good idea to establish trace links between system requirements, the software and
hardware requirements derived from them, and the architectural components to which they
were allocated. Tracing lets you verify that each system requirement was addressed in the
downstream deliverables. It also facilitates modifying the system in the future, as you can see
how a proposed new or altered system requirement will ripple change throughout the system.
 Poor requirements allocation decisions can result in:
 The software being expected to perform functions that hardware could have performed easier,
cheaper, or faster (or the reverse).
 A person being expected to perform functions that hardware or software could have performed
easier, cheaper, faster, or more safely (or the reverse).
 Inadequate performance.
 The inability to easily upgrade or replace components.
 Architecture Diagram
 As with business information systems, visual modeling is a powerful analysis
technique for specifying real-time systems. One useful model is an architecture
diagram. Figure 2 shows a portion of a simple architecture diagram for an
exercise treadmill. Each rectangle represents one of the major subsystems that will
provide all of the treadmill’s functions. The arrows between the boxes illustrate
the data and control interfaces between the subsystems, at a high level of
abstraction. Richer architecture description languages are available if a simple
block diagram like this doesn’t meet your needs.
 The subsystems shown in Figure 2 can be further elaborated into specific
hardware components (such as motors and sensors) and software components as
architectural analysis proceeds. A preliminary architectural analysis can reveal and
refine functional, interface, and quality requirements that might not have been
evident from other elicitation activities.
Figure 2. Partial architecture diagram for an exercise treadmill.
 Architecture Diagram

 Drawing architecture models during requirements analysis is clearly taking a

step into design.
 It’s a necessary step.
 Iterating on the architectural partitioning and the allocation of system
capabilities to subsystems and components is how an architect devises the most
appropriate and effective solution.
 You’ll need to perform further requirements elicitation, though.
 Functional requirements will guide the developers in both choosing appropriate
hardware components and designing user interface controls.
 Requirements for Devices Around Us: Embedded
System
 Quality attributes for embedded systems can be much more complex and
intertwined than those for other applications.
 The operating environment for embedded systems could involve temperature
extremes, vibration, shock, and other factors that dictate specific quality
considerations.
 Embedded systems also are subject to quality attributes and constraints that
apply only to physical systems.
 These include size, shape, weight, materials, flammability, connectors,
durability, cost, noise levels, and materials strength.
 All of these can increase the effort needed to validate the requirements
adequately.
 Performance

 A real-time system must satisfy the timing needs and constraints of the
operating environment. Therefore, include all processing deadlines for specific
operations in the requirements.
 However, performance goes beyond operational response times. It includes
such aspects as startup and reset times, power consumption, battery life, battery
recharge time, and heat dissipation.
 Energy management alone has multiple dimensions. How should the system
behave if the voltage drops momentarily, or under a particularly high current
load during startup, or if external power is lost and the device must switch to
battery backup power? Unlike software, hardware components can degrade
over time. What are the requirements for how long a battery maintains a given
profile of power over time before it needs to be replaced?
 Efficiency

 Efficiency is the internal quality counterpart to the externally observable attribute of

performance.
 Efficiency aspects of embedded systems focus on the consumption of resources,
including processor capacity, memory, disk space, communication channels, electrical
power, and network bandwidth. Requirements, architecture, and design become tightly
coupled with these matters.
 For instance, if the total power demand of the device could exceed the power available,
can it be designed to cut power to components that don’t need it all the time? The
requirements should specify the maximum anticipated consumption of various system
resources so designers can provide sufficient slack resources for future growth and
unexpected operating conditions. This is one of those situations for which concurrent
hardware and software design is vital.
 Reliability

 Real-time systems often have stringent reliability and availability requirements.

 Life-critical systems such as medical devices and airplane avionics offer little
room for failure.
 For instance, an artificial cardiac pacemaker that’s implanted into a patient’s body
must be expected to work reliably for years. When specifying reliability
requirements, realistically assess the likelihood and impact of failure so you don’t
over-engineer a product whose true reliability requirements aren’t as demanding
as you might think.
 Robustness
 Robustness has to do with how well the system responds to unexpected
operating conditions.
 One aspect of robustness is survivability.
 A good example of embedded systems designed for high survivability are
aircraft “black boxes,” electronic recording devices (orange, actually) that are
designed to survive the horrific trauma of an airplane crash.
 Other aspects of robustness have to do with how the system deals with faults,
or exceptions, that occur during execution and can lead to system failures. Both
hardware and software faults can lead to failures.
 Safety
 Safety requirements are vastly more significant for real-time systems than for
information systems; people are rarely injured by exploding spreadsheets.
 Begin your investigation of safety requirements by performing a hazard analysis.
This will reveal potential risks that your product could present.
 A fault tree analysis is a graphical, root-cause analysis technique for thinking about safety
threats and what factors could lead to them.
 This helps you focus on how to avoid specific combinations of risk factors materializing into
a problem.
 Safety requirements should address the risks and state what the system must do—or
must not do—to avoid them.
 Hardware devices often include some kind of emergency stop button or dead
man’s switch that will quickly turn the device off.
 Security
 The security of embedded systems is under much discussion these days
because of concerns about cyber attacks that could take over, disrupt, or
disable power plants, railroad control systems, and other critical
infrastructure.
 Theft of intellectual property from the memory of embedded systems is also
a risk.
 An attacker could potentially reverse engineer code to learn how the system
works, either to copy it or to attack it.
 Protecting embedded systems involves some of the same security measures
that host-based information systems need.
These include encryption, authentication, data integrity checks, and data privacy.
 Usability
 Many embedded systems include some kind of human-computer interface.
 Certain aspects of usability might be important when a person is using a physical
device in the field as opposed to a keyboard in the office.
 For instance, the display screens on products to be used outdoors must
accommodate different lighting situations. I once used a bank whose drive-up
ATM’s screen was completely unreadable when sunlight hit it at certain angles.
 Some usability constraints are imposed by legislation such as the Disabilities Act,
which requires compliant systems to provide accessibility aids for people who have
physical limitations.
 Embedded systems must accommodate users having a range of audio acuity and
frequency response, visual acuity and color vision, handedness and manual dexterity,
body size and reach.
 Design Constraints
 A vast majority of embedded systems applications end up in the heart of mass produced
electronic applications.
 Home appliances such as microwave ovens, toys, and dishwasher machines, automobile
systems such as anti-lock brakes and airbag deployment mechanisms, and personal devices
such as cellular phones and media players are only a few representative examples.
 These are systems with a high cost sensitivity to the resources included in a design due to the
high volumes in which they are produced.
 Moreover, designs need to be completed, manufactured and launched in time to hit a market
window to maximize product revenues.
 These constraints shape the design of embedded applications from beginning to end in their
life cycle.
 Therefore, the list of constraints faced by designers at the moment of conceiving an
embedded solution to a problem come from the different perspectives.
 The most salient constraints in the list include:
 Functionality: The system ability to perform the function it was designed
for.
 Cost: The amount of resources needed to conceive, design, produce,
maintain, and discard an embedded system.
 Performance: The system ability to perform its function on time.
 Size: Physical space taken by a system solution.
 Power and Energy: Energy required by a system to perform its function.
 Time to Market: The time it takes from system conception to
deployment.
 Maintainability: System ability to be kept functional for the longest of its
mature life.
The four actions supporting system maintain-
ability
 The cost overhead in the system NRE related to the design and validation
of maintenance and testing structures.
 The impact on the time-to-market caused by additional development time
required for the inclusion of maintainability features. This is also a factor in
the software design.
 The increase in recurrent costs caused by the additional hardware
components needed in the system to support testing and maintenance.
 Other factors affecting hardware maintainability in deployed systems
include problems of component obsolescence, accessibility to embedded
hardware components, and availability of appropriate documentation to
guide changes and repairs.
Assignment: Discuss briefly.

Requirements that affect design choices in Embedded Systems:

1. Processing power
2. Memory
3. Number of units
4. Power consumption
5. Development cost
6. Lifetime
7. Reliability
Reference:

 https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/3150/Require
ments-for-Devices-Around-Us-Embedded-Systems.aspx
 https://drive.google.com/file/d/1WEUJKqrgOHWURuxguJGYl815g1wWLhqf/vi
ew
 https://www.guru99.com/embedded-systems-tutorial.html