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

and is specific to the application. 4 . ± Software often has a fixed function. or even non-digital hardware may be used to increase performance or safety.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 -. application specific (ASIC). ± Special-purpose field programmable (FPGA).not just for diagnosing the computer.

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 .

implementation. 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.Embedded System(cont¶) ‡ Definitions ± FPGA(Field Programmable Gate Array) ‡ Programmable HW. verification on desktop workstations) 8 . but allows prototype to be designed quickly(circuit design.

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 .

low weight ± Safe and reliable ± Harsh environment ± Cost sensitivity 13 .Embedded System(cont¶) ‡ Design requirements ± Real time/reaction operation ± Small size.

Embedded Systems Programming. 6(5) 26-34]). "Perils of the PC Cache".Embedded System(cont¶) ± Real time/reactive operation ‡ Real time system operation: the correctness of a computation depends.. 14 .g. May 1993. cache memory [Philip Koopman. 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. in part.

and power circuits to reduce size. therefore. 15 .Embedded System(cont¶) ± Small size. 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. analog. ± Packaging and integration of digital. low weight ‡ Physically located within some larger artifact.

corrosion. lightning.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. depending on operating environment 16 . water. and general physical abuse ‡ Challenges: accurate thermal modeling and de-rating components differently for each design. shock. power supply fluctuations. fire.

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 .

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

power. and digital hardware plus software ± Power management ‡ Challenge: Ultra-low power design for long-term battery operation 20 . mechanical. network.Embedded System(cont¶) ± Controlling physical systems ‡ Challenge: Distributed system tradeoffs among analog.

Embedded System(cont¶) ‡ Embedded system lifecycle 21 .

Major Embedded OS ‡ ‡ ‡ ‡ QNX 4 RIOS Embedded Linux Windows CE VxWorks 22 .

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

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 .

± VxWork: Individual modules may be used in development and omitted in production systems.Major Embedded OS(cont¶) ‡ Architecture Comparison ± QNX: A very small microkernel surrounded by a team of cooperating processes that provide higher level OS services. ± WindowsCE: The operating system architecture of Windows CE is a hierarchical one. 25 . ± Linux: a layering structure and comprised of modules.

adaptive ‡ Fully preemptible 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.

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 .

contiguous area in the memory ‡ All the system services within QNX are built upon message passing primitives 30 .Major Embedded OS(cont¶) ‡ Interprocess Communication ± QNX: ‡ Message passing facilities ‡ a message delivered from one process to another need not occupy a single.

Unix Domain Sockets. wait queues. pipes and named pipes.Major Embeded OS(cont¶) ± Linux: ‡ Uses original Linux IPC mechanisms: signals. file locks. system V IPC. ‡ 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 .

only limited version of vfork() 34 . running on a flat memory model(virtual = physical) ‡ No paging. no memory sharing ‡ No fork() since no copy-on-write.Major Embedded OS(Cont¶) ‡ Memory management ± Q Clinux : ‡ Without a MMU. no protection.

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 .

± WindowsCE:has communication stacks of various kinds at the same level as kernel. 36 . HTTP.Major Embedded OS(cont¶) ‡ Network support ± QNX: contains low level network communication in its microkernel ± Linux: automatically get the most current Internet protocols. Supports IP. FTP and so on ± VxWorks: very good network support of almost all internet protocols.

Major Embedded OS(cont¶) ‡ Factors impact embedded operating system ± Application requirement impact ± Hardware impact 37 .

Waiting until this stage to debug adds unnecessary costs and delays. engineers often postpone the integration and verification task until a hardware prototype is available.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). new methodologies allow integration teams to verify their embedded systems applications while 38 meeting design and time-to-market goals. However. . When the system design includes developing application-specific integrated circuits (ASICS).

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 .

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

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 .

video.H/S interaction(cont¶) ± Avionics ‡ Fly-by-wire devices ‡ Navigation ‡ Flight control ± Certain ³software radio´ functions ± Printing and paper handling ± Signal processing(audio. 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 .

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¶) ‡ Co-design.

H/S interaction(cont¶) 51 .

H/S interaction(cont¶) ‡ Hardware/software codesign ± the cooperative design of hardware and software components. 52 . ± 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. ± the unification of currently separate hardware and software paths.

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 .

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

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 .

share the load 63 . the system is configured with N + X hardware modules. all the hardware modules that are equipped to perform system functions. typically X is much smaller than N ‡ Load sharing: under zero fault conditions.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.

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 .

many fault triggers will be generated for that unit. the isolation procedure involves interrogating the health of several units. all the units in the path from source to destination are probed for health 68 . If fault triggers are fuzzy in nature.Fault-tolerance ‡ Fault isolation If a unit is actually faulty. The main objective of fault isolation is to correlate the fault triggers and identify the faulty unit. For example. if protocol fault is the only fault reported.

In this case.Timing ‡ Real time: A real-time system provides specified system services with known timing and latency characteristics. which if exceeded. the timing constraints do not have an upper worst-case value. cause the application to fundamentally fail ‡ Soft real time:In a soft real-time system. 69 or the failure rates are acceptable . the timing constraints have an upper worst-case value. so that applications can be designed and developed that meet perscribed timing constraints ‡ Hard real time: In a hard real-time system. occasional longer latencies either do not really cause failures. but meet an acceptable statistical distribution of timings.

Sign up to vote on this title
UsefulNot useful