Embedded System

• A specialized computer system that is part

of a larger system or machine. Typically, an
embedded system is housed on a single
microprocessor board with the programs
stored in ROM. Some embedded systems
include an operating system, but many are
so specialized that the entire logic can be
implemented as a single program.
1
Embedded System Testing
Wei-Tek Tsai
Department of Computer Science and
Engineering
Arizona State University
Tempe, AZ 85287
2
Embedded System(cont’)

3
 Embedded System(cont’)
• Differences with desktop computing
– The human interface may be as simple as a flashing light
or as complicated as real-time robotic vision.
– The diagnostic port may be used for diagnosing the
system that is being controlled -- not just for diagnosing
the computer.
– Special-purpose field programmable (FPGA),
application specific (ASIC), or even non-digital
hardware may be used to increase performance or safety.
– Software often has a fixed function, and is specific to the
application.

4
Embedded System(cont’)

5
 Embedded System(cont’)
• Characteristics of Embedded Systems
– Application specific
• Jobs are known a priori
• Static scheduling of tasks and allocation of resources
– Real time
• Hardware/software tradeoff
• Exceptions
– Reactive
• Interacts with external environment continuously
– Hierarchy of behaviours
• Sequential and concurrent subbehaviours

6
 Embedded System(cont’)
• Characteristics of digital systems
– Application domain
• General purpose
• Dedicated computing and control systems
• Emulation and prototyping systems
– Degree of programmability
• Application level
• Instruction level
• Hardware level
– Hardware fabrication technology
• Bipolar versus CMOS
– Level of integration
• Discrete components versus integrated

7
 Embedded System(cont’)
• Definitions
– FPGA(Field Programmable Gate Array)
• Programmable HW; configurable gate level interconnection of
circuits after manufacturing
• Consists of a matrix of cells: Configurable Logic
Blocks(CLBs) and I/O Blocks(IOBs), with programmable
switches to provide the desired connections between blocks
• Slower than non-programmable devices, but allows prototype
to be designed quickly(circuit design, implementation,
verification on desktop workstations)

8
 Embedded System(cont’)
– ASIC(Application Specific Integrated Circuit)
• Custom designed chip to implement a digital
function/system
• Hardwired(non-programmable) gives the best
performance
• Must produce in volume to cover non-recurrent
engineering design cost

9
 Embedded System(cont’)
– ASIP(Application Specific Instruction
Processor)
• A microprocessor with special architecture design,
and instruction set chosen for a specific domain of
programs
• Easier to cover non-recurrent engineering cost since
ASIP has multiple applications

10
 Embedded System(cont’)
• HW/SW Co-Design
– Meeting system level objectives by exploiting
the synergism of HW and SW through their
concurrent design
– Simultaneously design the software architecture
of an application and the HW on which that SW
is implementation to meet performance, cost, or
reliability goals

11
 Embedded System(cont’)
– HW/SW Co-Simulation
• The joint simulation of HW and SW components
and their interaction

12
 Embedded System(cont’)
• Design requirements
– Real time/reaction operation
– Small size, low weight
– Safe and reliable
– Harsh environment
– Cost sensitivity

13
 Embedded System(cont’)
– Real time/reactive operation
• Real time system operation: the correctness of a computation
depends, in part, on the time at which it is delivered
• Reactive computation: the software executes in response to
external events
• Challenge: Worst case design analyses without undue
pessimism in the face of hardware with statistical performance
characteristics (e.g., cache memory [Philip Koopman, "Perils
of the PC Cache", Embedded Systems Programming, May
1993, 6(5) 26-34]).

14
 Embedded System(cont’)
– Small size, low weight
• Physically located within some larger artifact,
therefore, form factors may be dictated
• Weight might be critical in transportation and
portable systems for fuel economy or human
endurance
• Challenges:
– Non-rectangular, non-planar geometries.
– Packaging and integration of digital, analog, and power
circuits to reduce size.

15
 Embedded System(cont’)
– Safe and reliable
• Challenges:
– Low-cost reliability with minimal redundancy
– Harsh environment
• Many embedded systems do not operate in a controlled
environment
• Additional problems can be caused for embedded computing by
a need for protection from vibration, shock, lightning, power
supply fluctuations, water, corrosion, fire, and general physical
abuse
• Challenges: accurate thermal modeling and de-rating
components differently for each design, depending on operating
environment

16
 Embedded System(cont’)
– Cost sensitivity
• Challenge:Variable "design margin" to permit
tradeoff between product robustness and aggressive
cost optimization

17
 Embedded System(cont’)
• System level requirements for embedded
system
– End-product utility
– System safety & reliability
– Controlling physical systems
– Power management

18
 Embedded System(cont’)
– End-product utility
• Challenge: Software- and I/O-driven hardware
synthesis (as opposed to hardware-driven software
compilation/synthesis).
– System safety & reliability
• Challenges:
– Reliable software
– Cheap, available systems using unreliable components
– Electronic vs. non-electronic design tradeoffs

19
 Embedded System(cont’)
– Controlling physical systems
• Challenge: Distributed system tradeoffs among
analog, power, mechanical, network, and digital
hardware plus software
– Power management
• Challenge: Ultra-low power design for long-term
battery operation

20
 Embedded System(cont’)
• Embedded system lifecycle

21
 Major Embedded OS
• QNX 4 RIOS
• Embedded Linux
• Windows CE
• VxWorks

22
 Major Embedded OS (cont’)
• Supported processor
• QNX: all generic x86 based processors(386+)
• Linux: virtually on every general purpose micro-
processor(ARM, StrongARM, MIPS, Hitachi SH,
PowerPC, x86)
• WindowsCE: (x86, MIPS, Hitachi SH3 and SH4,
PowerPC and StrongArm processors)
• VxWorks: (PowerPc, 68K, CPU32, ColdFire, MCORE,
80x86 and Pentium, i960, ARM and StrongARM,
MIPS, SH, SPARC, NECV8xx, M32 R/D, RAD6000,
ST 20, TriCore)

23
 Major Embedded OS(cont’)
• Memory constraints
– QNX is the smallest
– Windows CE needs 350KB for a minimal
system
– Linux needs 125 – 256 KB fro a reasonable
configured kernel
– VxWorks: a few kilobytes for a deeply
embedded system
24
 Major Embedded OS(cont’)
• Architecture Comparison
– QNX: A very small microkernel surrounded by a team
of cooperating processes that provide higher level OS
services.
– Linux: a layering structure and comprised of modules.
– WindowsCE: The operating system architecture of
Windows CE is a hierarchical one.
– VxWork: Individual modules may be used in
development and omitted in production systems.

25
 Major Embedded OS(Cont’)
• Process Management
– QNX:
• Process manager is not in micro kernel
• Use message passing primitives to communicate
with other processes
• Scheduling is managed by the micro kernel
scheduler
• Scheduling methods: FIFO, RR, adaptive
• Fully preemptible
26
 Major Embedded OS(cont’)
– Linux:
• Implements threads in kernel
• Three classes of threads
– Real-time FIFO: having highest priority and not
preemptable
– Real-time RR: same as real-time FIFO but preemptable
– Time sharing: lowest prority

27
 Major Embedded OS(cont’)
– WindowsCE:
• Support both processes and threads
• Full memory protection applied to application
processes
• Thread scheduling is preemptive, using 8 different
priority levels
• A maximum of 32 simultaneous processes
• A process contains one or more threads

28
 Major Embedded OS(cont’)
– VxWorks:
• A multitasking kernel
• Transparently interleave task execution
• Uses Task Control Blocks(TCB’s) to keep track of
tasks
• Priority scheduling and priority based preemption
• RR scheduling only applies to the tasks of the same
priority

29
 Major Embedded OS(cont’)
• Interprocess Communication
– QNX:
• Message passing facilities
• a message delivered from one process to another
need not occupy a single, contiguous area in the
memory
• All the system services within QNX are built upon
message passing primitives

30
 Major Embeded OS(cont’)
– Linux:
• Uses original Linux IPC mechanisms: signals, wait
queues, file locks, pipes and named pipes, system V
IPC, Unix Domain Sockets.
• The embedded linux can choose any one of the IPC
methods for its particular application.

31
 Major Embedded OS(cont’)
– WindowsCE:
• Supports message passing between processes
• Supports memory mapping between processes

32
Major Embedded OS(Cont’)
– VxWorks:
• Shared memory
• Message passing queues
• Pipes

33
 Major Embedded OS(Cont’)
• Memory management
  Clinux :
• Without a MMU, running on a flat memory
model(virtual = physical)
• No paging, no protection, no memory sharing
• No fork() since no copy-on-write, only limited
version of vfork()

34
 Major Embedded OS(cont’)
– WindowsCE:
• More elaborate memory management
• Supports paged virtual memory partially
• Requires CPU to support a TLB but not a full page
model
• Full memory protection applies to application
processes

35
 Major Embedded OS(cont’)
• Network support
– QNX: contains low level network communication in its
microkernel
– Linux: automatically get the most current Internet
protocols.
– WindowsCE:has communication stacks of various
kinds at the same level as kernel. Supports IP, HTTP,
FTP and so on
– VxWorks: very good network support of almost all
internet protocols.
36
 Major Embedded OS(cont’)
• Factors impact embedded operating system
– Application requirement impact
– Hardware impact

37
 H/S interaction
• Today’s embedded system designers face the difficult task
of integrating and verifying application-specific software
and hardware with intellectual property (IP) such as
protocol stacks and commercial real-time operating
systems (RTOSs). When the system design includes
developing application-specific integrated circuits
(ASICS), engineers often postpone the integration and
verification task until a hardware prototype is available.
Waiting until this stage to debug adds unnecessary costs
and delays. However, new methodologies allow integration
teams to verify their embedded systems applications while
meeting design and time-to-market goals.

38
 H/S interaction(cont’)
• Semiconductior manufactures should not
ignore embedded software
• Software experts are unlikely to solve the
embedded software problem on their own

39
 H/S interaction(cont’)
• Software/Hardware Codesign
– Simultaneous design of both hardware and
software to implement in a desired function

40
 H/S interaction(cont’)
• Why is embedded software an issue for
semiconductor manufactures?
– Silicon without software getting rare
– Time-to-volume is often dominated by SW
development
– Software requirements affect hardware design
– Embedded software design is getting
harder(networking, complexity)
– Mainstream SW engineering is not addressing
embedded SW well

41
 H/S interaction(cont’)
• Why is embedded SW not just SW on small
computers?
– Interaction with physical processes(sensors, actutors,
etc.)
– Critical properties are not all functional(real-time, fault
recover, power, security, robustness)
– Heterogeneous(hareware/software, mixed architectures)
– Concurrent(interact with multi processes)
– Reactive(operating at the speed of environment)

42
 H/S interaction(cont’)
• Hardware experts have sth to teach to the
SW world
– Concurrency
– Reusability
– Reliability
– Heterogeneity

43
 H/S interaction(cont’)
• What an embedded program might look like

44
 H/S interaction(cont’)
• Simple example: controlling an inverted
pendulum with embedded SW

45
 H/S interaction(cont’)
• Metaphor for:
– Disk drive controllers
– Manufacturing equipment
– Automotive:
• Drive-by-wire devices
• Engine control
• Antilock braking systems, traction control

46
 H/S interaction(cont’)
– Avionics
• Fly-by-wire devices
• Navigation
• Flight control
– Certain “software radio” functions
– Printing and paper handling
– Signal processing(audio, video, radio)
– …
47
 H/S interaction(cont’)
• System HW/SW design methodology
– Specification capture
• Create model
• Select language for specification
– Exploration
• Allocate architectural components
• Partition the specification to the architectural
components

48
 H/S interaction(cont’)
– Refinement of specification
– Hardware and software design
• Synthesis
• Simulation
– Physical design
• Generate manufacture data for hardware
• Compile code for instruction sequence

49
 H/S interaction(cont’)
• Co-design, particularly important when designing embedded
systems or systems-on-a-chip
• There are many areas in which the co-design principle can
bring product enhancements
• Massive parallelism, distributed algorithms and special
architectures
• Efficient interfaces are required
• Low-Power Processors
• Reconfigurable Systems are capable of adapting to changing
environments or to incomplete specifications
• Parallel I/O on multiple PC's

50
H/S interaction(cont’)

51
 H/S interaction(cont’)
• Hardware/software codesign
– the cooperative design of hardware and software
components;
– the unification of currently separate hardware and
software paths;
– the movement of functionality between hardware and
software;
– the meeting of system-level objectives by exploiting
the synergism of hardware and software through their
concurrent design.
52
 H/W interaction(cont’)
• Why is it important?
– Reconfiguration: exploiting the synergy
between hardware and software

53
 H/S interaction(cont’)
– Embedded systems are application specific
systems which contain both hardware and
software tailored for a particular task and
generally part of a larger system
– Reusability: to provide design approaches that
scale up, without a total redesign for a legacy
product

54
 H/S interaction(cont’)
• Existing Problems
– Model Continuity Problem

55
 H/S interaction(cont’)
• Importance of Model Continuity
– many complex systems do not perform as
expected in their operational environment;
– continuity allows the validation of system level
models at all levels of hardware/software
implementation;
– trade-offs are easier to evaluate at several
stages

56
 H/S interaction(cont’)
• Consequences of losing such model continuity
– cost increases and schedule over-runs (due to
modifications late in phases);
– the ability to explore hardware/software trade-offs is
restricted (e.g. movement of functionality between,
modification of interfaces);
– state of the art applications require a case-by-case
analysis;
– different design cultures hamper integration

57
 H/S interaction(cont’)
• Solution
– Unified Design Environment: it is emphasized
that hardware design and software design use
the same integrated infrastructure, resulting in
an improvement of overall system performance,
reliability, and cost effectiveness.

58
 H/S interaction(cont’)
• Typical context for co-design process

An “ideal” process flow

59
 Memory Constraints
• Memory is usually a critical resource and
the memory size is often very restricted
• Both static and dynamic memory usage
within a task and the dynamic memory
usage due to communication should be
considered
• Mapping is also a problem

60
 Fault-tolerance
• Allowable system failure probability is 10 -10
per hour
• Software fault tolerance
• Hardware fault tolerance

61
 Fault-tolerance(cont’)
• Software fault tolerance
– Timeouts
– Audits
– Exception handling
– Task roll back
– Incremental reboot
– Voting

62
 Fault-tolerance(cont’)
• Hardware fault tolerance
– Redundancy Schemes
• One for one redundancy: each hardware module has a
redundant hardware module
• N + X redundancy: if N hardware modules are required to
perform system functions, the system is configured with N + X
hardware modules; typically X is much smaller than N
• Load sharing: under zero fault conditions, all the hardware
modules that are equipped to perform system functions, share
the load

63
 Fault-tolerance(cont’)
– Standby synchronization
• Bus cycle level synchronization
• Memory mirroring
• Message level synchronization
• Checkpoint level synchronization
• Reconciliation on takeover

64
 Fault-tolerance(cont’)
• Fault handling techniques
– Fault handling lifecycle
– Fault detection
– Fault isolation

65
 Fault-tolerance(cont’)

• Fault-handling lifecycle

66
 Fault-tolerance(cont’)
• Fault detection
– Sanity monitoring
– Watchdog monitoring
– Protocol faults
– In-service diagnostics
– Transient leaky bucket counters

67
 Fault-tolerance
• Fault isolation
If a unit is actually faulty, many fault triggers will
be generated for that unit. The main objective of
fault isolation is to correlate the fault triggers and
identify the faulty unit. If fault triggers are fuzzy
in nature, the isolation procedure involves
interrogating the health of several units. For
example, if protocol fault is the only fault
reported, all the units in the path from source to
destination are probed for health
68
 Timing
• Real time: A real-time system provides specified system
services with known timing and latency characteristics, so
that applications can be designed and developed that meet
perscribed timing constraints
• Hard real time: In a hard real-time system, the timing
constraints have an upper worst-case value, which if
exceeded, cause the application to fundamentally fail
• Soft real time:In a soft real-time system, the timing
constraints do not have an upper worst-case value, but meet
an acceptable statistical distribution of timings. In this case,
occasional longer latencies either do not really cause failures,
or the failure rates are acceptable

69