Embedded System

1
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.

2
Embedded System Testing

• Wei-Tek Tsai
• Department of Computer Science and Engineering
• Arizona State University
• Tempe, AZ 85287

3
Embedded System(cont)
4
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.

5
Embedded System(cont)
6
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

7
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

8
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)

9
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

10
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

11
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

12
Embedded System(cont)

• HW/SW Co-Simulation
• The joint simulation of HW and SW components and
  their interaction

13
Embedded System(cont)

• Design requirements
• Real time/reaction operation
• Small size, low weight
• Safe and reliable
• Harsh environment
• Cost sensitivity

14
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).

15
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.

16
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

17
Embedded System(cont)

• Cost sensitivity
• ChallengeVariable "design margin" to permit
  tradeoff between product robustness and
  aggressive cost optimization

18
Embedded System(cont)

• System level requirements for embedded system
• End-product utility
• System safety reliability
• Controlling physical systems
• Power management

19
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

20
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

21
Embedded System(cont)

• Embedded system lifecycle

22
Major Embedded OS

• QNX 4 RIOS
• Embedded Linux
• Windows CE
• VxWorks

23
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)

24
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

25
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.

26
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

27
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

28
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

29
Major Embedded OS(cont)

• VxWorks
• A multitasking kernel
• Transparently interleave task execution
• Uses Task Control Blocks(TCBs) to keep track of
  tasks
• Priority scheduling and priority based preemption
• RR scheduling only applies to the tasks of the
  same priority

30
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

31
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.

32
Major Embedded OS(cont)

• WindowsCE
• Supports message passing between processes
• Supports memory mapping between processes

33
Major Embedded OS(Cont)

• VxWorks
• Shared memory
• Message passing queues
• Pipes

34
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()

35
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

36
Major Embedded OS(cont)

• Network support
• QNX contains low level network communication in
  its microkernel
• Linux automatically get the most current
  Internet protocols.
• WindowsCEhas 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.

37
Major Embedded OS(cont)

• Factors impact embedded operating system
• Application requirement impact
• Hardware impact

38
H/S interaction

• Todays 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.

39
H/S interaction(cont)

• Semiconductior manufactures should not ignore
  embedded software
• Software experts are unlikely to solve the
  embedded software problem on their own

40
H/S interaction(cont)

• Software/Hardware Codesign
• Simultaneous design of both hardware and software
  to implement in a desired function

41
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

42
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)

43
H/S interaction(cont)

• Hardware experts have sth to teach to the SW
  world
• Concurrency
• Reusability
• Reliability
• Heterogeneity

44
H/S interaction(cont)

• What an embedded program might look like

45
H/S interaction(cont)

• Simple example controlling an inverted pendulum
  with embedded SW

46
H/S interaction(cont)

• Metaphor for
• Disk drive controllers
• Manufacturing equipment
• Automotive
• Drive-by-wire devices
• Engine control
• Antilock braking systems, traction control

47
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)

48
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

49
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

50
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

51
H/S interaction(cont)
52
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.

53
H/W interaction(cont)

• Why is it important?
• Reconfiguration exploiting the synergy between
  hardware and software

54
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

55
H/S interaction(cont)

• Existing Problems
• Model Continuity Problem

56
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

57
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

58
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.

59
H/S interaction(cont)

• Typical context for co-design process
• An ideal process flow

60
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

61
Fault-tolerance

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

62
Fault-tolerance(cont)

• Software fault tolerance
• Timeouts
• Audits
• Exception handling
• Task roll back
• Incremental reboot
• Voting

63
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

64
Fault-tolerance(cont)

• Standby synchronization
• Bus cycle level synchronization
• Memory mirroring
• Message level synchronization
• Checkpoint level synchronization
• Reconciliation on takeover

65
Fault-tolerance(cont)

• Fault handling techniques
• Fault handling lifecycle
• Fault detection
• Fault isolation

66
Fault-tolerance(cont)

• Fault-handling lifecycle

67
Fault-tolerance(cont)

• Fault detection
• Sanity monitoring
• Watchdog monitoring
• Protocol faults
• In-service diagnostics
• Transient leaky bucket counters

68
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

69
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 timeIn 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