Docstoc

Embedded system Testing - Embedded System

Document Sample
Embedded system Testing - Embedded System Powered By Docstoc
					          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
                                                  7
      • Discrete components versus integrated
      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,69
  or the failure rates are acceptable

				
DOCUMENT INFO