[attachment=1443]

ABSTRACT

Many embedded systems have substantially different design constraints than desktop computing applications. No single characterization applies to the diverse spectrum of embedded systems. However, some combination of cost pressure, long life-cycle, real¬-time requirements, reliability requirements, and design culture dysfunction can make it difficult to be successful applying traditional computer design methodologies and tools to embedded applications. Embedded systems in many cases must be optimized for life-cycle and business-driven factors rather than for maximum computing throughput. There is currently little tool support for expanding embedded computer design to the scope of holistic embedded system design. However, knowing the strengths and weaknesses of current approaches can set expectations appropriately, identify risk areas to tool adopters, and suggest ways in which tool builders can meet industrial needs.
INTRODUCTION:
If we look around us, today we see numerous appliances which we use daily, be it our refrigerator , the microwave oven, cars, PDAs etc. Most appliances today are powered by something beneath the sheath that makes them do what they do. These are tiny microprocessors, which respond to various keystrokes or inputs. These tiny microprocessors, working on basic assembly languages, are the heart of the appliances. We call them embedded systems. Of all the semiconductor industries, the embedded systems market place is the most conservative, and engineering decisions here usually lean towards established, low risk solutions. Welcome to the world of embedded systems, of computers that will not look like computers and wonâ„¢t function like any thing we are familiar with.
As the name signifies, an Ëœembedded systemâ„¢ is built into a noncomputing device, say a car, TV or toy. We can define an embedded system as a computing device, built in to a device that is not a computer, and meant for doing specific computing tasks. In general engineering terms, embedded systems are used for the control of industrial or physical processes. In computer science terms, embedded systems are distributed reactive systems. Typically these systems have to react to stimuli from their environment in real time. This can be of high importance in situations where a lot of signal processing must be carried out on the inputs inorder to compute the outputs. e.g., multimedia applications.
Embedded systems have been around us for about as long as computer themselves. These were first used in the late 1960s to control electro mechanical telephone switches. As computer industry has moved towards smaller systems over the last decade or so, embedded systems have also moved along with this trend.
Classification:
Embedded systems are divided into autonomous, realtime, networked & mobile categories.
Autonomous systems: They function in standalone mode. Many embedded systems used for process control in manufacturing units& automobiles fall under this category.
Realtime embedded systems: These are required to carry out specific tasks in a specified amount of time. These systems are extensively used to carryout time critical tasks in process control.
Networked embedded systems: They monitor plant parameters such as temperature, pressure and humidity and send the data over the network to a centralized system for on line monitoring.
Mobile gadgets: Mobile gadgets need to store databases locally in their memory. These gadgets imbibe powerful computing & communication capabilities to perform realtime as well as nonrealtime tasks and handle multimedia applications.
The embedded system is a combination of computer hardware, software, firmware and perhaps additional mechanical parts, designed to perform a specific function. A good example is an automatic washing machine or a microwave oven. Such a system is in direct contrast to a personal computer, which is not designed to do only a specific task. But an embedded system is designed to do a specific task with in a given timeframe, repeatedly, endlessly, with or without human interaction.
Hardware:
Good software design in embedded systems stems from a good understanding of the hardware behind it. All embedded systems need a microprocessor, and the kinds of microprocessors used in them are quite varied. A list of some of the common microprocessors families are: The Zilog Z8 family, Intel 8051/X86 family, Motorola 68K family and the power PC family. For processing of information and execution of programs, embedded system incorporates microprocessor or micro- controller. In an embedded system the microprocessor is a part of final product and is not available for reprogramming to the end user. An embedded system also needs memory for two purposes, to store its program and to store its data. Unlike normal desktops in which data and programs are stored at the same place, embedded systems store data and programs in different memories. This is simply because the embedded system does not have a hard drive and the program must be stored in memory even when the power is turned off. This type of memory is called ROM. Embedded applications commonly employ a special type of ROM that can be programmed or reprogrammed with the help of special devices.
UMS Hardware:
A common obstacle for developers has been the need to develop different sets of hardware and software for different devices. An intelligent washing machine uses a hardware chip different from that used by an intelligent wrist watch. In addition, the software running on the hardware chip is different. This often results in increased costs and time taken for development.
The Universal Micro System(UMS) from cradle technologies is a solution for this problem. UMS is a general purpose chip built around a simple instruction set. It can be used to develop applications for embedded devices because all the functionality required for a specific device can be modeled in the software. Since the major functionality provided in UMS is through software, the processor and memory units must be very fast and the input, output units must be programmable and versatile. UMS uses a large number of high speed, low power and small RISC based processors on a single chip. Each processing element coupled with two digital signal processors form a multi stream processor(MSP), which processes voluminous chunks of data. Developing on UMS represents a significant infrastructure cost savings, dramatic decrease in time to market and an unprecedented opportunity to combine many functions and redefine products in the market.
UMS hardware architecture:



Software:
Embedded software has grown complex and pervasive enough to attract the attention of computer scientists. Embedded softwareâ„¢s main task is to engage the physical world interacting directly with sensors & actuators. The most pressing problem is how to adapt existing software techniques to meet the challenges of the physical world. Software for embedded systems must handle problems beyond those found in application software for desktops or mainframe computers. Embedded software often has several things to do at once - respond to external events, cope with unusual conditions without human intervention while being subjected to deadlines. So embedded software is harder to design. Embedded systems are increasingly networked which introduced significant complications such as downloadable modules that dynamically reconfigure the system. Moreover, consumers demand ever more elaborate functionality which greatly increases software complexity. These systems can no longer be designed by a single engineer, fine tuning tens of kilobytes of assembly code. Embedded software design is art as much as it is science. We must know how fast our system operates and know how critical it is to meet each deadline. If deadlines are absolute, then it is a hard real time system else it is a soft real time system.
Functionality has steadily shifted from hardware to software. C has become the language of choice for embedded programmers, because it has the benefit of processor independence. Languages such as C++, Java are also used. Home devices will flourish best if they present a uniform API to application programmers, and an ideal interface is Java. Open Service Gateway Initiative(OSGI) , a java based system that combines services with event on security mechanisms, is defining a set of open standard software application interfaces for building Open Service Gateways including Residential Gateways . Embedded Graphical User Interface™s (GUI) are growing more elaborate day by day. Developers now have to contend with such arcana as a color pallet. In some applications, an embedded GUI has to compete with mechanical controls. In luxury cars, for e.g, Graphical displays are starting to replace mechanical speedo meters and tacho meters.Visualization tools are designed to find bugs that are hard to find with theusual Breakpoint and explore debugging paradigm. They work beautifully on Heisenberg bugs “ so called because they disappear when we start looking for them.
Any source code written in C or C++ or assembly language must be converted into an executable image that can be loaded onto a ROM chip. For this purpose three distinct steps are involved.
Cross compiled or assembled to generate object files.
Object files must be linked into a relocatable program.
Physical memory address must be assigned to the relocatable program.
RTOS:
To run any software we need operating system. Embedded systems do not require a complete operating system, which may make the system bulky, but only the basic functionalities of the operating system in a real time environment “ RTOS. Off-the-shelf operating systems for these systems began to appear in the late 1970™s, and today several dozen viable options are available.Embedded operating systems are available in variety of flavours: Windows NT, LINUX, Windows CE 3.0, PalmOS, QNX, ROMDOS, JBED, RT kernel, Tiny BIOS, Turbo task, Nucleus plus/Tasking, Diamond,ThreadX (#$@%) etc. Out of these , a few major players have emerged , such as Vxworks, PSOS, neculeus, windows CE, ThreadX and linux. ˜Inferno™ and ˜Chai™ are the two popular environments that are used to develop applications.
Embedded Databases:
Embedded Databases are in software applications and in hardware devices, both mobile and fixed. The purpose of Embedded Database is data storage and retrieval with minimum intervention and minimum system impact. The rapid increase in the number of Telecomputers, the explosive growth of E-commerce and general migration to wireless technologies have put Embedded Database development on the IT short list. In a world of mobile computers and smart devices , size matters because memory and storage are very limited. A key factor is a small memory foot print. Embedded database vendors and developers tend to focus on smallness of their achievements. Sybaseâ„¢s Ultra Lite, a version of SQL which is any where portable database has a foot print of 50 kilobytes.
Ëœe2Bâ„¢: The internet gives machines a way to communicate. For embedded internet, communication channels are seen in technologies such as blue tooth, CEbus, upnp and TCP/IP; linguistic mechanisms in notions such as java RMI; HTTP & SNMP. Embedding internet technologies is also called as Ëœe2Bâ„¢ or embedded to business.
Firmware:
Many authors use software and firmware in the same sense. Actually firmware consists of microcode programs executed from very high speed control storage. Commonly used object programs placed in ROMs and PROMs are also some times referred to as firmware. The problem with any approach to the field firmware updates is that if the upgrade contains a flaw, the target system may become an expensive doorstop. Many of the pitfalls are obvious and straight forward, but some insidious defects donâ„¢t appear until after a product has been deployed. Any well designed firmware upgrade system must be able to recover from user errors and other catastrophic events to the fullest extent possible. The best way to accomplish this is to implement a fundamentally sound firmware update strategy that avoids these problems entirely. A microprogrammer is a system level description of how an embedded system beheves before, during and after the firmware update process. This is designed to help avoid many of the problems to downloadable firmware. ËœFlexwareâ„¢ is a flexible firmware development environment.
Other common parts found on many embedded systems:
¢ UART& RS232
¢ PLD
¢ ASIC™s& FPGA™s
¢ Watch dog timer e.t.c.
Design process:
Embedded system design is a quantitative job. The pillars of the system design methodology are the separation between function and architecture, is an essential step from conception to implementation. In recent past, the search and industrial community has paid significant attention to the topic of hardware-software (HW/SW) codesign and has tackled the problem of coordinating the design of the parts to be implemented as software and the parts to be implemented as hardware avoiding the HW/SW integration problem marred the electronics system industry so long. In any large scale embedded systems design methodology, concurrency must be considered as a first class citizen at all levels of abstraction and in both hardware and software. Formal models & transformations in system design are used so that verification and synthesis can be applied to advantage in the design methodology. Simulation tools are used for exploring the design space for validating the functional and timing behaviors of embedded systems.
Hardware can be simulated at different levels such as electrical circuits, logic gates, RTL e.t.c. using VHDL description. In some environments software development tools can be coupled with hardware simulators, while in others the software is executed on the simulated hardware. The later approach is feasible only for small parts of embedded systems.


FIG:
Development
Cycle

Design of an embedded system using Intelâ„¢s 80C188EB chip is shown in the figure. Inorder to reduce complexity, the design process is divided in four major steps: specification, system synthesis, implementation synthesis and performance evaluation of the prototype.
Specification: During this part of the design process, the informal requirements of the analysis are transformed to formal specification using SDL.
System synthesis: For performing an automatic HW/SW partitioning, the system synthesis step translates the SDL specification to an internal system model switch contains problem graph& architecture graph. After system synthesis, the resulting system model is translated back to SDL.
Implementation synthesis: SDL specification is then translated into conventional implementation languages such as VHDL for hardware modules and C for software parts of the system.
Prototyping: On a prototyping platform, the implementation of the system under development is executed with the software parts running on multiprocessor unit and the hardware part running on a FPGA board known as phoenix, prototype hardware for Embedded Network Interconnect Accelerators.
Applications:
Embedded systems are finding their way into robotic toys and electronic pets, intelligent cars and remote controllable home appliances. All the major toy makers across the world have been coming out with advanced interactive toys that can become our friends for life. ËœFurbyâ„¢ and ËœAIBOâ„¢ are good examples at this kind. Furbies have a distinct life cycle just like human beings, starting from being a baby and growing to an adult one. In AIBO first two letters stands for Artificial Intelligence. Next two letters represents robot . The AIBO is robotic dog. Embedded systems in cars also known as Telematic Systems are used to provide navigational security communication & entertinment services using GPS, satellite. Home appliances are going the embedded way. LG electronics digital DIOS refrigerator can be used for surfing the net, checking e-mail, making video phone calls and watching TV.IBM is developing an air conditioner that we can control over the net. Embedded systems cover such a broad range of products that generalization is difficult. Here are some broad categories.
Aerospace and defence electronics: fire control, radar, robotics/sensors, sonar.
Automotive: autobody electronics, auto power train, auto safety, car information systems.
Broadcast & entertainment: Analog and digital sound products, camaras, DVDs,
Set top boxes, virtual reality systems, graphic products.
Consumer/internet appliances: Business handheld computers, business network computers/terminals, electronic books, internet smart handheld devices, PDAs.
Data communications: Analog modems, ATM switches, cable modems, XDSL modems, Ethernet switches, concentrators.
Digital imaging: Copiers, digital still cameras, Fax machines, printers, scanners.
Industrial measurement and control: Hydro electric utility research & management traffic management systems, train marine vessel management systems.
Medical electronics: Diagnostic devices, real time medical imaging systems, surgical devices, critical care systems.
Server I/O: Embedded servers, enterprise PC servers, PCI LAN/NIC controllers, RAID devices, SCSI devices.
Telecommunications : ATM communication products, base stations, networking switches, SONET/SDH cross connect, multiplexer.
Mobile data infrastructures: Mobile data terminals, pagers, VSATs, Wireless LANs, Wireless phones.
CONCLUSION:
Embedded systems have virtually entered every sphere of our life, right from the time we work out on tread mills to the cars that we drive today. The possibilities in this field are only limited by our imagination.Many of the embedded systems are managed by human controllers by some sort of man machine interface-for example a cash register,a cell phone, a TV screen or a PC interface.It is this MMI that often represents the most costly investment in the systemâ„¢s development,interms of both time and money.
References:
[1] Embedded Systems Programming. Miller Freeman, San Francisco, ISSN 1040-3272.
[2] Daniel D. Gajski. Frank Vahid, Sanjiv Narayan & Jie Gong, Specification and Design of Embedded Systems. PTR Prentice Hall, Englewood Cliffs NJ, 1994.
[3J Jack Ganssle, Art of programming Embedded Systems, Academic Press, San Diego. 1992.
[4J Shem-Tov Levi & Ashok Agrawala, Fault Tolerant System Design, McGraw¬Hill, New York, 1994.
[5] Nancy Leveson, Safeware: system safety and computers, Addison-Wesle,1994..

1. Introduction
We live in a world today in which software plays a critical part. The most critical soft ware is not running on large systems and PCs. rather, it runs inside the infrastructure and in the devices that we use every day. Our transportation, communications, and energy systems won't work if the embedded software contained in our cars, phones, routers and power plants crashes.
Evolution of a software system is a natural process. In most systems, evolution takes place during the maintenance phase of their life cycles. Those systems that have reached their limit in evolution have usually reached their end of useful life and may have to be replaced. However, there are systems in which evolution occurs during the operational phase of their life cycles. Such systems are designed to evolve while in use or, in other words, be adaptable. Semantically adaptable systems are of particular interest to industry as such systems often times adapt themselves to environment change with little or no intervention from their developing or maintaining organization. Since embedded systems usually have a restricted hardware configuration, it is difficult to apply the techniques developed for non-embedded systems directly to embedded systems. This paper focuses on evolution through adaptation and develops the concepts and techniques for semantic evolution in embedded systems. As the first step in the development of a software solution, architectures of software systems themselves have to be made semantically evolvable. In this paper we explore various architectural alternatives for the semantic evolution of embedded systems-- these architectures are based on four different techniques that we have identified for semantic evolution in embedded systems. The development of these architectures follows the systematic, process provided by the non-functional requirement (NFR) framework, which also permits the architectures to be rated in terms of their evolvability. As the field of embedded systems is vast, this paper concentrates on those embedded systems that can be remotely controlled. In this application domain the embedded system is connected to an external controller by a communication page link such as Ethernet, serial, radio frequency, etc., and receives commands from and sends responses to the external controller via the communication link. The architectures developed in this paper have been partly validated by applying them in a real embedded system--a test instrument used for testing cell phones. These architectures and techniques for semantic evolution in this application domain give a glimpse of what can be done in achieving semantic evolution in software-implemented systems.
Approximately 3 billion embedded CPUs are sold each year, with smaller (4-, 8-, and 16-bit) CPUs dominating by quantity and aggregate dollar amount [1]. Yet, most research and tool development seems to be focused on the needs of high-end desktop and military/aerospace embedded computing. This paper seeks to expand the area of discussion to encompass a wide range of embedded systems.
The extreme diversity of embedded applications makes generalizations difficult. Nonetheless, there is emerging interest in the entire range of embedded systems and the related field of hardware/software codesign.
This paper and the accompanying tutorial seek to identify significant areas in which embedded computer design differs from more traditional desktop computer design. They also present "design challenges" encountered in the course of designing several real systems. These challenges are both opportunities to improve methodology and tool support as well as impediments to deploying such support to embedded system design teams. In some cases research and development has already begun in these areas -- and in other cases it has not.
The observations in this paper come from the author's experience with commercial as well as military applications, development methodologies, and life-cycle support. All characterizations are implicitly qualified to indicate a typical, representative, or perhaps simply an anecdotal case rather than a definitive statement about all embedded systems. While it is understood that each embedded system has its own set of unique requirements, it is hoped that the generalizations and examples presented here will provide a broad-brush basis for discussion and evolution of CAD tools and design methodologies.
An embedded system is a special-purpose computer system designed to perform one or a few dedicated functions, often with real-time computing constraints. It is usually embedded as part of a complete device including hardware and mechanical parts. In contrast, a general-purpose computer, such as a personal computer, can do many different tasks depending on programming. Embedded systems have become very important today as they control many of the common devices we use.
Since the embedded system is dedicated to specific tasks, design engineers can optimize it, reducing the size and cost of the product, or increasing the reliability and performance. Some embedded systems are mass-produced, benefiting from economies of scale.
Physically, embedded systems range from portable devices such as digital watches and MP3 players, to large stationary installations like traffic lights, factory controllers, or the systems controlling nuclear power plants. Complexity varies from low, with a single microcontroller chip, to very high with multiple units, peripherals and networks mounted inside a large chassis or enclosure.
The design of this invisible, embedded software is crucial to all of us. Yet, there has been a real shortage of good information as to effective design and implementation practices specific to this very different world. Make no mistake, it is indeed different and often more difficult to design embedded software than more traditional programs. Time, and the interaction of multiple tasks in real-time, must be managed.
In general, "embedded system" is not an exactly defined term, as many systems have some element of programmability. For example, Handheld computers share some elements with embedded systems ” such as the operating systems and microprocessors which power them ” but are not truly embedded systems, because they allow different applications to be loaded and peripherals to be connected.
2. History
In the earliest years of computers in the 1930-40s, computers were sometimes dedicated to a single task, but were far too large and expensive for most kinds of tasks performed by embedded computers of today. Over time however, the concept of [[programmable controllers]] evolved from traditional [[electromechanical]] sequencers, via solid state devices, to the use of computer technology.
One of the first recognizably modern embedded system was the [[Apollo Guidance Computer]], developed by [[Charles Stark Draper]] at the MIT Instrumentation Laboratory. At the project's inception, the Apollo guidance computer was considered the riskiest item in the Apollo project as it employed the then newly developed monolithic integrated circuits to reduce the size and weight. An early mass-produced embedded system was the [[Autonetics D-17]] guidance computer for the [[Minuteman (missile) |Minuteman missile]], released in 1961. It was built from [[transistor]] [[digital circuit logic]] and had a [[hard disk]] for main memory. When the Minuteman II went into production in 1966, the D-17 was replaced with a new computer that was the first high-volume use of integrated circuits. This program alone reduced prices on quad [[Sheffer stroke#NAND gate|nand gate ICs]] from $1000/each to $3/each, permitting their use in commercial products.
Since these early applications in the 1960s, embedded systems have come down in price and there has been a dramatic rise in processing power and functionality. The first [[microprocessor]] for example, the [[Intel 4004]] was designed for [[calculator]] s and other small systems but still required many external memory and support chips. In 1978 National Engineering Manufacturers Association released a "standard" for programmable microcontrollers, including almost any computer-based controllers, such as single board computers, numerical, and event-based controllers.
As the cost of microprocessors and microcontrollers fell it became feasible to replace expensive knob-based [[analog electronics analog]] components such as [[potentiometer]]s and [[variable capacitor]]s with up/down buttons or knobs read out by a microprocessor even in some consumer products. By the mid-1980s, most of the common previously external system components had been integrated into the same chip as the processor and this modern form of the [[microcontroller]] allowed an even more widespread use, which by the end of the decade was the norm rather than the exception for almost all electronics devices. Embedded systems are the applications that fuel some of the microprocessors that play a hidden but crucial role in our everyday lives. These are the tiny, quick, and smart microprocessors that live inside printers, answering machines, elevators, cars, cash machines, refrigerators, thermostats, wristwatches, and even toasters. Embedded systems are on the cutting edge of consumer electronics, poised to revolutionize various technologies by making them "smarter." A branch of the embedded-systems industry wants to see some of this newly smart equipment hooked up to the Internet, so that networking capabilities become a ubiquitous feature of modern machines.
The history of embedded systems goes back at least to the sixties, but the expense and limitations of the early systems limited their use. Embedded systems really took off in 1992, when the PC/104 Consortium was founded by Ampro, RTD, and other manufacturers. The group established a format for Intel microprocessors based on a motherboard approximately four inches square, and just under an inch high. The boards were stackable, allowing a very powerful computer to be assembled in a box approximately four inches square, or even less.
The PC/104 was initially targeted at military and medical markets, where it became widely used and respected. When the processor power increased enough to handle multimedia applications, PC/104-based kiosks became possible, and eventually common.
Today, there are estimated to be well over 100 different companies making PC/104 products. There are PC/104 cards to add Ethernet, FireWire, hard drives, RAM drives, video cards, audio cards, general I/O, flash cards, modems, GPS, cellular telephone, wireless Internet, and more, to the PC/104 motherboard of your choice. Some off-the-shelf PC/104 cases can handle up to 13 or more cards, so your budget is your only constraint.
Kiosk development software is also progressing. Amulet Technologies (AmuletTechnologies.com) demonstrated a system that will allow LCD touch screens to be programmed in HTML. Since it usually takes C++ programming and several months to program a touch screen interface, the Amulet Technologies system is a major breakthrough. In addition to saving time and money, the technology leaves the interface design to an HTML layout artist, not an engineer. (We managed to program a simple interface with it in less than fifteen minutes from the time we opened the box.) It would be easy and economical to use this technology to make an interface for a hot tub, or a table-top ordering system for customers at restaurants.
Interestingly, many of the exhibitors at the 2002 Embedded Systems Conference were marketing systems much smaller than the PC/104 format. In fact, some of the exhibitors were just selling chips, primarily to add Internet connectivity to products ranging from cars to coffee makers.
Microchip design has advanced so far over the last few years that it's now possible to build a complete computer system on a chip, including wireless Internet connectivity. These chips can easily be added to thousands of products, and soon will be.
It is unavoidable that computer will continue to become cheaper, smaller and more powerful, and that eventually they will be inexpensive enough to put in nearly every product, including soda straws and matchbooks. In addition, nearly all computer equipped products will have some kind of access to either local networks, or the Internet.
Imagine a bathroom shower that will maintain exactly whatever water temperature you tell it to maintain. Aside from meaning no child would ever be accidentally scalded in a bathtub again, this would also mean more efficient and comfortable showers. A computer equipped bathtub would also be smart enough to turn it self off before it overflowed, and send you e-mail to let you know when your bath was ready.
Over the next decade, many common household items will be given embedded systems, reinventing them, and changing forever how we interface with them.
Like desktop publishing, and later the Internet, embedded systems is a technology that will fundamentally, and permanently, change the way advertising and marketing works. It will also permanently change the kind of products that are made, and how they are made.
It's about time, too. For all the benefits industrialization has brought, it has also brought a host of problems as well. The problems go beyond VCR's and microwaves that take an engineering degree to program.
For several hundred years, man has increasingly adjusted life to fit the needs of industrialization and the corporate structure that has grown to support it. In the process, we've become slaves of the machines built to sustain us, and some would argue, slaves to the system itself.
The development of intelligent products, and intelligent product marketing, made possible by embedded systems, will at least offer the possibility of a world where machines exist for the convenience of people, and not the reverse. Given the tools we have now, this kind of dream is no longer impossible.
The rise of embedded systems marks a new phase in industrialization. We've mechanized civilization. Now we have to civilize mechanization.
3. Examples of Embedded Systems
Figure 1 shows one possible organization for an embedded system.
Figure 1. An embedded system encompasses the CPU as well as many other resources.
In addition to the CPU and memory hierarchy, there are a variety of interfaces that enable the system to measure, manipulate, and otherwise interact with the external environment. Some differences with desktop computing may be:
¢ 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.
Table 1. Four example embedded systems with approximate attributes.
In order to make the discussion more concrete, we shall discuss four example systems (Table 1). Each example portrays a real system in current production, but has been slightly generalized to represent a broader cross-section of applications as well as protect proprietary interests. The four examples are a Signal Processing system, a Mission Critical control system, a Distributed control system, and a Small consumer electronic system. The Signal Processing and Mission Critical systems are representative of traditional military/aerospace embedded systems, but in fact are becoming more applicable to general commercial applications over time.
Using these four examples to illustrate points, the following sections describe the different areas of concern for embedded system design: computer design, system-level design, life-cycle support, business model support, and design culture adaptation.
Desktop computing design methodology and tool support is to a large degree concerned with initial design of the digital system itself. To be sure, experienced designers are cognizant of other aspects, but with the recent emphasis on quantitative design life-cycle issues that aren't readily quantified could be left out of the optimization process. However, such an approach is insufficient to create embedded systems that can effectively compete in the marketplace. This is because in many cases the issue is not whether design of an immensely complex system is feasible, but rather whether a relatively modest system can be highly optimized for life-cycle cost and effectiveness.
While traditional digital design CAD tools can make a computer designer more efficient, they may not deal with the central issue -- embedded design is about the system, not about the computer. In desktop computing, design often focuses on building the fastest CPU, then supporting it as required for maximum computing speed. In embedded systems the combination of the external interfaces (sensors, actuators) and the control or sequencing algorithms is or primary importance. The CPU simply exists as a way to implement those functions. The following experiment should serve to illustrate this point: ask a roomful of people what kind of CPU is in the personal computer or workstation they use. Then ask the same people which CPU is used for the engine controller in their car (and whether the CPU type influenced the purchasing decision).
In high-end embedded systems, the tools used for desktop computer design are invaluable. However, many embedded systems both large and small must meet additional requirements that are beyond the scope of what is typically handled by design automation. These additional needs fall into the categories of special computer design requirements, system-level requirements, life-cycle support issues, business model compatibility, and design culture issues.
Embedded systems span all aspects of modern life and there are many examples of their use.
Telecommunications systems employ numerous embedded systems from telephone switches for the network to mobile phones at the end-user. Computer networking uses dedicated routers and network bridges to route data.
Consumer electronics include personal digital assistants (PDAs), mp3 players, mobile phones, videogame consoles, digital cameras, DVD players, GPS receivers, and printers. Many household appliances, such as microwave ovens, washing machines and dishwashers, are including embedded systems to provide flexibility, efficiency and features. Advanced HVAC systems use networked thermostats to more accurately and efficiently control temperature that can change by time of day and season. Home automation uses wired- and wireless-networking that can be used to control lights, climate, security, audio/visual, etc., all of which use embedded devices for sensing and controlling.
Transportation systems from flight to automobiles increasingly use embedded systems. New airplanes contain advanced avionics such as inertial guidance systems and GPS receivers that also have considerable safety requirements. Various electric motors ” brushless DC motors, induction motors and DC motors ” are using electric/electronic motor controllers. Automobiles, electric vehicles. and hybrid vehicles are increasingly using embedded systems to maximize efficiency and reduce pollution. Other automotive safety systems such as anti-lock braking system (ABS), Electronic Stability Control (ESC/ESP), and automatic four-wheel drive.
Medical equipment is continuing to advance with more embedded systems for vital signs monitoring, electronic stethoscopes for amplifying sounds, and various medical imaging (PET, SPECT, CT, MRI) for non-invasive internal inspections.
4. Characteristics
Embedded systems are designed to do some specific task, rather than be a general-purpose computer for multiple tasks. Some also have [[Real-time computing real-time]] performance constraints that must be met, for reason such as safety and usability; others may have low or no performance requirements, allowing the system hardware to be simplified to reduce costs.
# Embedded systems are not always separate devices. Most often they are physically built-in to the devices they control. {{Fact date=September 2007}}.
# The software written for embedded systems is often called [[firmware]], and is stored in read-only memory or [[Flash memory]] chips rather than a disk drive. It often runs with limited computer hardware resources: small or no keyboard, screen, and little memory.
4.1 User Interfaces:
Embedded systems range from no user interface at all — dedicated only to one task — to full user interfaces similar to desktop operating systems in devices such as PDAs.
4.2 Simple Systems:
Simple embedded devices use buttons, [[LED]] s, and small character- or digit-only displays, often with a simple [[Menu (computing) |menu system]].
4.3 In More Complex Systems:
A full graphical screen, with [[touch screen touch]] sensing or screen-edge buttons provides flexibility while minimizing space used: the meaning of the buttons can change with the screen, and selection involves the natural behavior of pointing at what's desired.
Handheld systems often have a screen with a "joystick button" for a pointing device.
The rise of the [[World Wide Web]] has given embedded designers another quite different option: providing a web page interface over a network connection. This avoids the cost of a sophisticated display, yet provides complex input and display capabilities when needed, on another computer. This is successful for remote, permanently installed equipment such as Pan-Tilt-Zoom cameras and network routers.
4.4 CPU Platforms:
Embedded processors can be broken into two broad categories: ordinary microprocessors (µP) and microcontrollers (µC), which have many more peripherals on chip, reducing cost and size. Contrasting to the personal computer and server markets, a fairly large number of basic [[CPU architecture]]s are used; there are [[Von Neumann architecture|Von Neumann]] as well as various degrees of [[Harvard architecture]]s, [[RISC]] as well as non-RISC and [[VLIW]]; word lengths vary from 4-bit to 64-bits and beyond (mainly in [[Digital signal processor|DSP]] processors) although the most typical remain 8/16-bit. Most architectures come in a large number of different variants and shapes, many of which are also manufactured by several different companies.
A long but still not exhaustive list of common architectures are: [[65816]], [[65C02]], [[68HC08]], [[68HC11]], [[68k]], [[8051]], [[ARM architecture ARM]], [[Atmel AVR|AVR]], [[Blackfin]], [[C167 family|C167]], [[Coldfire]], [[COP8]], [[Zilog Z8|eZ8]], [[eZ80]], [[FR-V]], [[Renesas H8|H8]], [[HT48FXX Flash I/O type series|HT48]], [[M16C]], [[M32C]], [[MIPS architecture|MIPS]], [[MSP430]], [[PIC microcontroller|PIC]], [[PowerPC]], [[R8C]], [[Super Harvard Architecture Single-Chip Computer|SHARC]], [[ST6]], [[SuperH]], [[TLCS-47]], [[TLCS-870]], [[TLCS-900]], [[Tricore]], [[V850]], [[x86 architecture|x86]], [[XE8000]], [[Z80]], etc.
4.4.1 Ready Made Computer Boards:
[[PC/104]] and PC/104+ are examples of available ''ready made'' computer boards intended for small, low-volume embedded and ruggedized systems. These often use [[DOS]], [[Linux]], [[NetBSD]], or an embedded [[real-time operating system]] such as [[MicroC/OS-II]], [[QNX]] or [[VxWorks]].
4.4.2 ASIC and FPGA Solutions:
A common configuration for very-high-volume embedded systems is the [[system on a chip]] (SoC), an [[application-specific integrated circuit]] (ASIC), for which the CPU core was purchased and added as part of the chip design. A related scheme is to use a [[field-programmable gate array]] (FPGA), and program it with all the logic, including the CPU.
4.5 Peripherals:
Embedded Systems talk with the outside world via [[peripheral]] s, such as:
*Serial Communication Interfaces (SCI): [[RS-232]], [[RS-422]], [[RS-485]] etc
*Synchronous Serial Communication Interface: [[I2C]], [[JTAG]], [[Serial Peripheral Interface Bus|SPI]], SSC and ESSI
*[[Universal Serial Bus]] (USB)
*Networks: [[Ethernet]], [[Controller Area Network]], [[LonWorks]], etc
*Timers: [[PLL]] (s), Capture/Compare and [[Time Processing Unit]] s
*Discrete IO: aka [[General Purpose Input/Output]] (GPIO)
*Analog to Digital/Digital to Analog (ADC/DAC)
4.6 Tools:
As for other software, embedded system designers use [[compiler]]s, [[Assembly language#Assembler|assembler]]s, and [[debugger]]s to develop embedded system software. However, they may also use some more specific tools:
* In circuit debuggers or emulators (see next section).
* Utilities to add a checksum or [[Cyclic redundancy check|CRC]] to a program, so the embedded system can check if the program is valid.
* For systems using [[digital signal processing]], developers may use a math workbench such as [[MATLAB]], [[Simulink]], [[MathCad]], or [[Mathematica]] to simulate the mathematics. They might also use libraries for both the host and target which eliminates developing DSP routines as done in [[DSPnano RTOS]] and [[Unison Operating System]].
* Custom compilers and linkers may be used to improve optimization for the particular hardware.
* An embedded system may have its own special language or design tool, or add enhancements to an existing language such as [[Forth (programming language)|Forth]] or [[BASIC Stamp|Basic]].
* Another alternative is to add a [[Real-time operating system]] or [[Embedded operating system]], which may have DSP capabilities like [[DSPnano RTOS]].
Software tools can come from several sources:
* Software companies that specialize in the embedded market
* Ported from the [[GNU]] software development tools
* Sometimes, development tools for a personal computer can be used if the embedded processor is a close relative to a common PC processor
As the complexity of embedded systems grows, higher level tools and operating systems are migrating into machinery where it makes sense. For example, [[cellphone]] s, [[personal digital assistant]]s and other consumer computers often need significant software that is purchased or provided by a person other than the manufacturer of the electronics. In these systems, an open programming environment such as [[Linux]], [[NetBSD]], [[OSGi]] or [[Embedded Java]] is required so that the third-party software provider can sell to a large market.
4.7 Debugging:
Embedded [[Debugging]] may be performed at different levels, depending on the facilities available. From simplest to most sophisticated they can be roughly grouped into the following areas:
* Interactive resident debugging, using the simple shell provided by the embedded operating system (e.g. Forth and Basic)
* External debugging using logging or serial port output to trace operation using either a monitor in flash or using a debug server like the [[Remedy Debugger]] which even works for heterogeneous [[multicore]] systems.
* An in-circuit debugger (ICD), a hardware device that connects to the microprocessor via a [[JTAG]] or NEXUS interface. This allows the operation of the microprocessor to be controlled externally, but is typically restricted to specific debugging capabilities in the processor.
* An [[in-circuit emulator]] replaces the microprocessor with a simulated equivalent, providing full control over all aspects of the microprocessor.
* A complete [[emulator]] provides a simulation of all aspects of the hardware, allowing all of it to be controlled and modified and allowing debugging on a normal PC.
Unless restricted to external debugging, the programmer can typically load and run software through the tools, view the code running in the processor, and start or stop its operation. The view of the code may be as [[assembly code]] or [[source-code]].
4.8 Reliability:
Embedded systems often reside in machines that are expected to run continuously for years without errors and in some cases recover by themselves if an error occurs. Therefore the software is usually developed and tested more carefully than that for personal computers, and unreliable mechanical moving parts such as disk drives, switches or buttons are avoided.
Specific reliability issues may include:
#The system cannot safely be shut down for repair, or it is too inaccessible to repair. Examples include space systems, undersea cables, navigational beacons, bore-hole systems, and automobiles.
#The system must be kept running for safety reasons. "Limp modes" are less tolerable. Often backups are selected by an operator. Examples include aircraft navigation, reactor control systems, safety-critical chemical factory controls, train signals, engines on single-engine aircraft.
#The system will lose large amounts of money when shut down: Telephone switches, factory controls, bridge and elevator controls, funds transfer and market making, automated sales and service.
A variety of techniques are used, sometimes in combination, to recover from errors -- both software bugs such as memory leaks, and also [[soft error]] s in the hardware:
* [[watchdog timer]] that resets the computer unless the software periodically notifies the watchdog
* Subsystems with redundant spares that can be switched over to
* Software "limp modes" that provide partial function
* [[Immunity Aware Programming]]
4.9 High vs. Low Volume:
For high volume systems such as [[Digital audio player portable music players]] or [[mobile phone]]s, minimizing cost is usually the primary design consideration. Engineers typically select hardware that is just good enough to implement the necessary functions.
For low-volume or prototype embedded systems, general purpose computers may be adapted by limiting the programs or by replacing the operating system with a [[real-time operating system
5. Computer Design Requirements
Embedded computers typically have tight constraints on both functionality and implementation. In particular, they must guarantee real time operation reactive to external events, conform to size and weight limits, budget power and cooling consumption, satisfy safety and reliability requirements, and meet tight cost targets.
5.1. Real time/reactive operation
Real time system operation means that the correctness of a computation depends, in part, on the time at which it is delivered. In many cases the system design must take into account worst case performance. Predicting the worst case may be difficult on complicated architectures, leading to overly pessimistic estimates erring on the side of caution. The Signal Processing and Mission Critical example systems have a significant requirement for real time operation in order to meet external I/O and control stability requirements.
Reactive computation means that the software executes in response to external events. These events may be periodic, in which case scheduling of events to guarantee performance may be possible. On the other hand, many events may be aperiodic, in which case the maximum event arrival rate must be estimated in order to accommodate worst case situations. Most embedded systems have a significant reactive component.
Design challenge:
¢ Worst case design analyses without undue pessimism in the face of hardware with statistical performance characteristics.
5.2. Small size, low weight
Many embedded computers are physically located within some larger artifact. Therefore, their form factor may be dictated by aesthetics, form factors existing in pre-electronic versions, or having to fit into interstices among mechanical components. In transportation and portable systems, weight may be critical for fuel economy or human endurance. Among the examples, the Mission Critical system has much more stringent size and weight requirements than the others because of its use in a flight vehicle, although all examples have restrictions of this type.
Design challenges:
¢ Non-rectangular, non-planar geometries.
¢ Packaging and integration of digital, analog, and power circuits to reduce size.
5.3. Safe and reliable
Some systems have obvious risks associated with failure. In mission-critical applications such as aircraft flight control, severe personal injury or equipment damage could result from a failure of the embedded computer. Traditionally, such systems have employed multiply-redundant computers or distributed consensus protocols in order to ensure continued operation after an equipment failure.
However, many embedded systems that could cause personal or property damage cannot tolerate the added cost of redundancy in hardware or processing capacity needed for traditional fault tolerance techniques. This vulnerability is often resolved at the system level as discussed later.
Design challenge:
¢ Low-cost reliability with minimal redundancy.
5.4. Harsh environment
Many embedded systems do not operate in a controlled environment. Excessive heat is often a problem, especially in applications involving combustion (e.g., many transportation applications). 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. For example, in the Mission Critical example application the computer must function for a guaranteed, but brief, period of time even under non-survivable fire conditions.
Design challenges:
¢ Accurate thermal modeling.
¢ De-rating components differently for each design, depending on operating environment.
5.5. Cost sensitivity
Even though embedded computers have stringent requirements, cost is almost always an issue (even increasingly for military systems). Although designers of systems large and small may talk about the importance of cost with equal urgency, their sensitivity to cost changes can vary dramatically. A reason for this may be that the effect of computer costs on profitability is more a function of the proportion of cost changes compared to the total system cost, rather than compared to the digital electronics cost alone. For example, in the Signal Processing system cost sensitivity can be estimated at approximately $1000 (i.e., a designer can make decisions at the $1000 level without undue management scrutiny). However, with in the Small system decisions increasing costs by even a few cents attract management attention due to the huge multiplier of production quantity combined with the higher percentage of total system cost it represents. Embedded computers typically have tight constraints on both functionality and implementation. In particular, they must guarantee real time operation reactive to external events, conform to size and weight limits, budget power and cooling consumption, satisfy safety and reliability requirements, and meet tight cost targets.
Design challenge:
¢ Variable "design margin" to permit tradeoff between product robustness and aggressive cost optimization.
6. System-level requirements
In order to be competitive in the marketplace, embedded systems require that the designers take into account the entire system when making design decisions.
6.1. End-product utility
The utility of the end product is the goal when designing an embedded system, not the capability of the embedded computer itself. Embedded products are typically sold on the basis of capabilities, features, and system cost rather than which CPU is used in them or cost/performance of that CPU.
One way of looking at an embedded system is that the mechanisms and their associated I/O are largely defined by the application. Then, software is used to coordinate the mechanisms and define their functionality, often at the level of control system equations or finite state machines. Finally, computer hardware is made available as infrastructure to execute the software and interface it to the external world. While this may not be an exciting way for a hardware engineer to look at things, it does emphasize that the total functionality delivered by the system is what is paramount.
Design challenge:
¢ Software- and I/O-driven hardware synthesis (as opposed to hardware-driven software compilation/synthesis).
6.2. System safety & reliability
An earlier section discussed the safety and reliability of the computing hardware itself. But, it is the safety and reliability of the total embedded system that really matters. The Distributed system example is mission critical, but does not employ computer redundancy. Instead, mechanical safety backups are activated when the computer system loses control in order to safely shut down system operation.
A bigger and more difficult issue at the system level is software safety and reliability. While software doesn't normally "break" in the sense of hardware, it may be so complex that a set of unexpected circumstances can cause software failures leading to unsafe situations. This is a difficult problem that will take many years to address, and may not be properly appreciated by non-computer engineers and managers involved in system design decisions (discusses the role of computers in system safety).
Design challenges:
¢ Reliable software.
¢ Cheap, available systems using unreliable components.
¢ Electronic vs. non-electronic design tradeoffs.
6.3. Controlling physical systems
The usual reason for embedding a computer is to interact with the environment, often by monitoring and controlling external machinery. In order to do this, analog inputs and outputs must be transformed to and from digital signal levels. Additionally, significant current loads may need to be switched in order to operate motors, light fixtures, and other actuators. All these requirements can lead to a large computer circuit board dominated by non-digital components.
In some systems "smart" sensors and actuators (that contain their own analog interfaces, power switches, and small CPUS) may be used to off-load interface hardware from the central embedded computer. This brings the additional advantage of reducing the amount of system wiring and number of connector contacts by employing an embedded network rather than a bundle of analog wires. However, this change brings with it an additional computer design problem of partitioning the computations among distributed computers in the face of an inexpensive network with modest bandwidth capabilities.
Design challenge:
¢ Distributed system tradeoffs among analog, power, mechanical, network, and digital hardware plus software.
6.4. Power management
A less pervasive system-level issue, but one that is still common, is a need for power management to either minimize heat production or conserve battery power. While the push to laptop computing
has produced "low-power" variants of popular CPUs, significantly lower power is needed in order to run from inexpensive batteries for 30 days in some applications, and up to 5 years in others.
Design challenge:
¢ Ultra-low power design for long-term battery operation.
7. Life-cycle support
Figure 2 shows one view of a product life-cycle.
Figure 2. An embedded system lifecycle.
First a need or opportunity to deploy new technology is identified. Then a product concept is developed. This is followed by concurrent product and manufacturing process design, production, and deployment. But in many embedded systems, the designer must see past deployment and take into account support, maintenance, upgrades, and system retirement issues in order to actually create a profitable design. Some of the issues affecting this life-cycle profitability are discussed below.
7.1. Component acquisition
Because an embedded system may be more application-driven than a typical technology-driven desktop computer design, there may be more leeway in component selection. Thus, component acquisition costs can be taken into account when optimizing system life-cycle cost. For example, the cost of a component generally decreases with quantity, so design decisions for multiple designs should be coordinated to share common components to the benefit of all.
Design challenge:
¢ Life-cycle, cross-design component cost models and optimization rather than simple per-unit cost.
7.2. System certification
Embedded computers can affect the safety as well as the performance the system. Therefore, rigorous qualification procedures are necessary in some systems after any design change in order to assess and reduce the risk of malfunction or unanticipated system failure. This additional cost can negate any savings that might have otherwise been realized by a design improvement in the embedded computer or its software. This point in particular hinders use of new technology by resynthesizing hardware components -- the redesigned components cannot be used without incurring the cost of system recertification.
One strategy to minimize the cost of system recertification is to delay all design changes until major system upgrades occur. As distributed embedded systems come into more widespread use, another likely strategy is to partition the system in such a way as to minimize the number of subsystems that need to be recertified when changes occur. This is a partitioning problem affected by potential design changes, technology insertion strategies, and regulatory requirements.
Design challenge:
¢ Partitioning/synthesis to minimize recertification costs.
7.3. Logistics and repair
Whenever an embedded computer design is created or changed, it affects the downstream maintenance of the product. A failure of the computer can cause the entire system to be unusable until the computer is repaired. In many cases embedded systems must be repairable in a few minutes to a few hours, which implies that spare components and maintenance personnel must be located close to the system. A fast repair time may also imply that extensive diagnosis and data collection capabilities must be built into the system, which may be at odds with keeping production costs low.
Because of the long system lifetimes of many embedded systems, proliferation of design variations can cause significant logistics expenses. For example, if a component design is changed it can force changes in spare component inventory, maintenance test equipment, maintenance procedures, and maintenance training. Furthermore, each design change should be tested for compatibility with various system configurations, and accommodated by the configuration management database.
Design challenge:
¢ Designs optimized to minimize spares inventory.
¢ High-coverage diagnosis and self-test at system level, not just digital component level.
7.4. Upgrades
Because of the long life of many embedded systems, upgrades to electronic components and software may be used to update functionality and extend the life of the embedded system with respect to competing with replacement equipment. While it may often be the case that an electronics upgrade involves completely replacing circuit boards, it is important to realize that the rest of the system will remain unchanged. Therefore, any special behaviors, interfaces, and undocumented features must be taken into account when performing the upgrade. Also, upgrades may be subject to recertification requirements.
Of special concern is software in an upgraded system. Legacy software may not be executable on upgraded replacement hardware, and may not be readily cross-compiled to the new target CPU. Even worse, timing behavior is likely to be different on newer hardware, but may be both undocumented and critical to system operation.
Design challenge:
¢ Ensuring complete interface, timing, and functionality compatibility when upgrading designs.
7.5. Long-term component availability
When embedded systems are more than a few years old, some electronic components may no longer be available for production of new equipment or replacements. This problem can be especially troublesome with obsolete processors and small-sized dynamic memory chips.
When a product does reach a point at which spare components are no longer economically available, the entire embedded computer must sometimes be redesigned or upgraded. This redesign might need to take place even if the system is no longer in production, depending on the availability of a replacement system. This problem is a significant concern on the Distributed example system.
Design challenge:
¢ Cost-effectively update old designs to incorporate new components.
8. Business model
The business models under which embedded systems are developed can vary as widely as the applications themselves. Costs, cycle time, and the role of product families are all crucial business issues that affect design decisions.
8.1. Design vs. production costs
Design costs, also called Non-Recurring Engineering costs (NRE), are of major importance when few of a particular embedded system are being built. Conversely, production costs are important in high-volume production. Embedded systems vary from single units to millions of units, and so span the range of tradeoffs between designs versus production costs.
At the low-volume end of the spectrum, CAD tools can help designers complete their work with a minimum of effort. However, at the high-volume end of the spectrum the designs may be simple enough and engineering cost such a small fraction of total system cost that extensive hand-optimization is performed in order to reduce production costs.
CAD tools may be able to outperform an average engineer at all times, and a superior engineer on very large designs (because of the limits of human capacity to deal with complexity and repetition). However, in small designs some embedded computer designers believe that a superior human engineer can outperform CAD tools. In the Small system example a programmer squeezed software into a few hundred bytes of memory by hand when the compiler produced overly large output that needed more memory than was available. It can readily be debated whether CAD tools or humans are "better" designers, but CAD tools face skepticism in areas that require extraordinary optimization for size, performance, or cost.
Design challenge:
¢ Intelligently trade off design time versus production cost.
8.2. Cycle time
The cycle time between identification of a product opportunity and product deployment (also called Time to Market) can be quite long for embedded systems. In many cases the electronics are not the driving force; instead, product schedules are driven by concerns such as tooling for mechanical components and manufacturing process design. Superficially, this would seem to imply that design time for the electronics is not an overriding concern, but this is only partially true.
Because the computer system may have the most malleable design, it may absorb the brunt of changes. For example, redesign of hardware was required on the Mission Critical example system when it was found that additional sensors and actuators were needed to meet system performance goals. On the Small example system, delays in making masked ROM changes in order to revise software dominate concerns about modifications (and programmable memory is too expensive). So, although the initial design is often not in the critical path to product deployment, redesign of the computer system may need to be done quickly to resolve problems.
Design challenge:
¢ Rapid redesign to accommodate changing form factors, control algorithms, and functionality requirements.
8.3. Product families
In many cases embedded system designs are not unique, and there are a variety of systems of various prices and capabilities forming a product family. To the extent that system designers can reuse components, they lower the total cost of all systems in the product family.
However, there is a dynamic tension between overly general solutions that satisfy a large number of niche requirements, and specifically optimized designs for each point in a product family space. Also, there may be cases in which contradictory requirements between similar systems prevent the use of a single subsystem design. In the Mission Critical and Small examples different customers require different interfaces between the embedded system and their equipment. In the Distributed example regulatory agencies impose different safety-critical behavior requirements depending on the geographic area in which the system is deployed.
Design challenge:
¢ Customize designs while minimizing component variant proliferation.
9. Design culture
Design is a social activity as well as a technical activity. The design of desktop computers and CPUs in particular, has matured in terms of becoming more quantitative in recent years. With this new maturity has come an emphasis on simulation and CAD tools to provide engineering tradeoffs based on accurate performance and cost predictions.
Computer designers venturing into the embedded arena must realize that their culture (and the underlying tool infrastructure) is unlike what is commonly practiced in some other engineering disciplines. But, because embedded system design requires a confluence of engineering skills, successful computer designers and design methodologies must find a harmonious compromise with the techniques and methodologies of other disciplines as well as company management. Also, in many cases the engineers building embedded computer systems are not actually trained in computer engineering (or, perhaps not even electrical engineering), and so are not attuned to the culture and methodologies of desktop computer design.
9.1. Computer culture vs. other cultures
A specific problem is that computer design tools have progressed to the point that many believe it is more cost-effective to do extensive simulation than build successive prototypes. However, in the mechanical arena much existing practice strongly favors prototyping with less exhaustive up-front analysis. Thus, it may be difficult to convince project managers (who may be application area specialists rather than computer specialists) to spend limited capital budgets on CAD tools and defer the gratification of early prototype development in favor of simulation.
Design challenge:
¢ Make simulation-based computer design accessible to non-specialists.
9.2. Accounting for cost of engineering design
One area of common concern is the effectiveness of using engineers in any design discipline. But, some computer design CAD tools are very expensive, and in general organizations have difficulty trading off capital and tool costs against engineering time. This means that computer designers may be deprived of CAD tools that would reduce the total cost of designing a system.
Also, in high-volume applications engineering costs can be relatively small when compared to production costs. Often, the number of engineers is fixed, and book-kept as a constant expense that is decoupled from the profitability of any particular system design, as is the case in all four example systems. This can be referred to as the "Engineers Are Free" syndrome. But, while the cost of engineering time may have a small impact on product costs, the unavailability of enough engineers to do work on all the products being designed can have a significant opportunity cost (which is, in general, unmeasured).
Design challenge:
¢ Improved productivity via using tools and methodologies may be better received by managers if it is perceived to increase the number of products that can be designed, rather than merely the efficiency of engineers on any given product design effort. This is a subtle but, in practice, important distinction.
9.3. Inertia
In general, the cost of change in an organization is high both in terms of money and organizational disruption. The computer industry can be thought of as being forced to change by inexorable exponential growth in hardware capabilities. However, the impact of this growth seems to have been delayed in embedded system development. In part this is because of the long time that elapses between new technology introduction and wide-scale use in inexpensive systems. Thus, it may simply be that complex designs will force updated CAD tools and design methodologies to be adopted for embedded systems in the near future.
On the other hand, the latest computer design technologies may not have been adopted by many embedded system makers because they aren't necessary. Tool development that concentrates on the ability to handle millions of transistors may simply not be relevant to designers of systems using 4- and 8-bit microprocessors that constitute the bulk of the embedded CPU market. And, even if they are useful, the need for them may not be compelling enough to justify the pain and up-front expense of change so long as older techniques work.
That is not to say that new tools aren't needed, but rather that the force of cultural inertia will only permit adoption of low-cost tools with significant advantages to the problem at hand.
However, the impact of this growth seems to have been delayed in embedded system development. In part this is because of the long time that elapses between new technology introduction and wide-scale use in inexpensive systems. Tool development that concentrates on the ability to handle millions of transistors may simply not be relevant to designers of systems using 4- and 8-bit microprocessors that constitute the bulk of the embedded CPU market. On the other hand, the latest computer design technologies may not have been adopted by many embedded system makers because they aren't necessary.
Design challenge:
¢ Find/create design tools and methodologies that provide unique, compelling advantages for embedded design.
¢ Rapid redesign to accommodate changing form factors, control algorithms, and functionality requirements.
.
10. Application
Embedded systems are omnipresent and play significant roles in modern-day life. Embedded systems are also diverse and can be found in consumer electronics, such as digital cameras, DVD players and printers; in industrial robots; in advanced avionics, such as missile guidance systems and flight control systems; in medical equipment, such as cardiac arrhythmia monitors and cardiac pacemakers; in automotive designs, such as fuel injection systems and auto-braking systems. Embedded systems have significantly improved the way we live today-and will continue to change the way we live tomorrow.
The availability of low-cost computational-powerful micro-controllers has made it possible to extend the performance and the functionality of the embedded controllers used in automotive industry to limits that were unthinkable only a few years ago. Nowadays, top class cars are equipped with many (more than 80) embedded controllers that handle different subsystems, such as engine, gear, brakes, suspensions, windows, and dash-board
The every increasing complexity and challenges of the automotive requirements in terms of drivability, safety, emissions and fuel consumption imposed by car manufacturers and regulations call for more powerful design approaches and expose the need for a more structured and accurate design flow. The adopted design methodologies have to ensure the development of embedded systems achieving the requested specification and meeting the extremely tight cost and development-time constraints imposed by the market.
Embedded systems already play an important role not only in consumer electronics but also in many important and safety-critical systems in applications such as avionics, space, railway and transport, process control and medical systems. There are, for instance, already many embedded systems in cars with critical control functions (e.g. ABS braking systems, airbags), and these will become much more widely used in the automotive industry once they can be delivered at prices acceptable to the automotive market.
Hybrid system techniques can provide significant contributions to the improvement of the design flow for embedded systems in the automotive industry, since they allow to clearly represent the complex combination of time and event-based behaviors as well as the interactions between continuous and discrete phenomena. Hybrid formalisms and methodologies proved to be very effective in handling several critical issues of the design flow such as:
¢ formalization of system specifications;
¢ representation of embedded controller inputs/outputs;
¢ plant and environment modeling;
¢ representation of multirate asynchronous control loops;
¢ description of the control-flow and data-flow components of control algorithms;
¢ validation and verification of control algorithms and their implementations;
¢ description of the HW/SW implementation requirements.
11. Conclusions
Many embedded systems have requirements that differ significantly both in details and in scope from desktop computers. In particular, the demands of the specific application and the interface with external equipment may dominate the system design. Also, long life-cycles and in some cases extreme cost sensitivity require more attention to optimization based on these goals rather than maximizing the computational throughput.
The business and cultural climates in many embedded system design situations are such that traditional simulation-based computer design techniques may not be viable in their current form. Such methodologies may not be cost-effective given constraints on categories of expenditures, may not be seen as worthwhile by non-computer-trained professionals, or may simply be solving the wrong problems.
Recent interest in hardware/software codesign is a step in the right direction, as it permits tradeoffs between hardware and software that are critical for more cost-effective embedded systems. However, to be successful future tools may well need to increase scope even further to include life-cycle issues and business issues.
12. References
1]. wikipedia.org
2]. embeddedstar.org
3]. embeddedindia.com
4]. zdnet.com
5]. Real time concepts for embedded systems by Qing LI.
Contents
1]: Introduction ¦¦ 03
2]: History ¦¦ 06
3]: Examples of Embedded Systems ¦¦ 10
4]: Characteristics ¦¦ 14
4.1]: User Interfaces
4.2]: Simple Systems
4.3]: In more complex systems
4.4]: CPU platforms
4.4.1]: Ready made computer
boards
4.4.2]: ASIC and FPGA solutions
4.5]: Peripherals
4.6]: Tools
4.7]: Debugging
4.8]: Reliability
4.9]: High vs. Low Volume
5]: Computer Design Requirements ¦¦ 19
5.1]: Real time/reactive operation
5.2]: Small size, low weight
5.3]: Safe and reliable
5.4]: Harsh environment
5.5]: Cost sensitivity
6]: System-level requirements ¦¦ 22
6.1]: End-product utility
6.2]: System safety & reliability
6.3]: Controlling physical systems
6.4]: Power management
7]: Life-cycle support ¦¦ 25
7.1]: Component acquisition 7.2]: System certification 7.3]: Logistics and repair 7.4]: Upgrades 7.5]: Long-term component availability
8]: Business Model ¦¦ 29
8.1]: Design vs. production costs 8.2]: Cycle time 8.3]: Product families
9]: Design culture ¦¦ 31 9.1]: Computer culture vs. other cultures 9.2]: Accounting for cost of engineering 9.3]: Inertia
10]: Application ¦¦ 34
11]: Conclusions ¦¦ 36
12]: Reference ¦¦ 37

An embedded system can be defined as the computing device that has computer hardware, either with software embedded in it as one of its most important component. It may be an independent system or a part of a larger system. The emergence of embedded systems is a recent development. As a scientific discipline it resembles the state of microelectronics (and VLSI design, in particular) around 1980. Todayâ„¢s challenge is similar to back then, except that the stakes are probably higher. Embedded systems will appear in virtually all devices, and intelligent devices have the tendency to oust their "stupid" counterparts from the market place, just like CD players have ousted gramophone players. Thanks to developments in microelectronics, the computing power of the desktop computers is now becoming available on the palmtops. Embedded systems are heterogeneous. Since they are mixtures of hardware and software, trade-off is important design decisions: do we realize a function in hardware or in software But embedded systems are more heterogeneous than just combining computer science & digital electronics. and text provides a brief introduction to the wide eld of embedded systems. It covers the history and the main aspects of hard- and software design for embedded systems. The basic concepts of synthesis and automated verications are introduced and a short overview of well-known metrics, which are used to describe the economical and technical at-tributes of a system, is provided. Additionally the deferenceâ„¢s between commonly used operating systems are discussed.

Anti-lock breaking system is designed to help the driver maintain steering control during hard breaking , especially in slippery conditions .It prevents the wheels from locking up , helping you maintain steering control during braking . In a similar situation, driving a car equipped with four-wheel ABS, it would be easier for you to steer your vehicle while braking.

[attachment=3285]

SEMINAR ON Embedded Systems

---

Presented by:-
Rupali Kusumbe

---

CONTENTS
¢ INTRODUCTION
¢ HISTORY
¢ MICROPROCESSOR
¢ MICROCONTROLLER
¢ CLASSFICATION
¢ APPLICATION AREA
¢ VIEWS
¢ SOME PROBLEMS

HISTORY
First embedded system was the APOLLO GUIDANCE COMPUTER.
In 1961 Autonetics D-17 guidance computer used in missile.
Microprocessor INTEL 4004 was designed .



EMBEDDED SYSTEM
A system that has an embedded software in a device that make a system dedicated for an application or for a specific part of an application or product ,or a part of a larger system.
What is an Embedded System
An Embedded System is microprocessor or microcontroller based system that is embedded as a subsystem, in a larger system (which may or may not be a computer system).
Physically, embedded systems range from portable devices such as digital watches and MP3 players, to large stationary installations like traffic lights, factory controllers, or the systems controlling nuclear power plants



MICROPROCESSOR
A microprocessor is used as general-purpose processor when large embedded software has to be located in the external memory chips.
In general , a microprocessor is a single VLSI chip that
has a CPU.
CPU executes information stores in the memory.



MICROCONTROLLER
A microcontroller is a single chip VLSI unit having limited capabilities.
No addition of external memory.
Microcontroller is of 8-bit, 16-bit, 32-bit, 64-bit.
General Characteristics of Embedded Systems
Perform a single as well as multitasking.
Increasingly high performance and real time constrained.
Power, cost and reliability are important considerations.
HW-SW systems
Software is used for more features and flexibility
Hardware (processors, memory etc. are used for performance and security.



CLASSIFICATION OF EMBEDDED SYSTEM
Small scale embedded systems.
Medium scale embedded system.
Sophisticated embedded systems.
Small scale embedded systems
Single 8-bit or 16-bit microcontroller.
Less number of hardware and software.
Battery operated.
Use of C language.
Example:-Telephone







Medium scale embedded systems
Few number of 16-bit or 32-bit microcontroller.
Number of hardware and software increases.
Use of C++/C/JAVA.
Example:-Music system
Sophisticated embedded systems
Number of 32-bit or 64-bit microcontroller.
Increase in the Number of hardware and software.
Use of C++/VISUAL C++/JAVA.
Use of software function such as encryption.
Example:-Mobile phone , Smart card



Application areas
Automotive electronics
Aircraft electronics
Trains
Telecommunication


Application areas
Views on embedded System
It is estimated that each year embedded software is written five times as much as 'regular' software
The vast majority of CPU-chips produced world-wide today are used in the embedded market ... ; only a small portion of CPU's is applied in PC's
... the number of software-constructors of Embedded Systems will rise from 2 million in 1994 to 10 million in 2010;
... the number of constructors employed by software-producers 'merely' rises from 0.6 million to 1.1 million.


Some problems
¢ How can we capture the required behaviour of complex
systems
¢ How do we validate specifications
¢ How do we translate specifications efficiently into
implementation
¢ Do software engineers ever consider electrical power
¢ How can we check that we meet real-time constraints
¢ How do we validate embedded real-time software
(large volumes of data, testing may be safety-critical)

THANK YOU.

[attachment=3292]

CHAPTER 1
INTRODUCTION
You read about it everywhere: distributed computing is the next revolution, Perhaps relegating our desktop computers to the museum. But in fact the age of distributed computing has been around for quite a while. Every time we withdraw money from an ATM, start our car, use our cell phone, or microwave our dinner, microprocessors are at work performing dedicated functions. These are examples of just a very few of the thousands of embedded systems.
Until recently the vast majority of these embedded systems used 8- and 16-bit microprocessors, requiring little in the way of sophisticated software development tools, including an Operating System (OS). But the 32-bit processors are now driving an explosion in high-volume embedded applications. And a new trend towards integrating a full system-on-a-chip (SOC) promises a further dramatic expansion for 32-bit embedded applications as we head into the 21st century.
Aerospace companies were the first end-markets for embedded systems, driven by military and space applications. But this market has never developed the growth potential of the newer commercial applications. In the past five years, the major end-markets for embedded systems have been telecommunications, computer networking, and office equipment. But, now we see consumer and automotive electronics as major emerging markets. And looming on the horizon is the suspected wave of networked appliances, with Sun Microsystems, IBM, Microsoft and others targeting products and standards; envisioning billions of embedded network connections running embedded JAVA applications across a network.
CHAPTER 2
HISTORY
The first recognizably modern embedded system was the Apollo Guidance Computer, developed by Charles Stark Draper at the MIT Instrumentation Laboratory. Each flight to the moon had two. They ran the inertial guidance systems of both the command module and LEM.
At the project's inception, the apollo guidance computer was considered the riskiest item in the apollo project. The use of the then new monolithic integrated circuits, to reduce the size and weight, increased this risk.
The first mass-produced embedded system was the guidance computer for the Minuteman missile in 1961. It was the Autonetics D-17 guidance computer, built using discrete transistor logic and a hard disk for main memory. When the Minuteman II went into production in 1966, the D-17 was replaced with a new computer that used integrated circuits, and was the first volume user of them. Without this program, integrated circuits might never have reached a usable price-point.
The crucial design features of the Minuteman computer were that its guidance algorithm could be reprogrammed later in the program, to make the missile more accurate, and the computer could also test the missile, saving cable and connector weight.
CHAPTER 3
EMBEDDED APPLICATION DEVELOPMENT CHARACTERISTICS
What characterizes an embedded system? Usually it means that there are a set of pre-defined, specific functions to be performed, and that the resources available (e.g., memory, power, processor speed, computational functionality) are constrained. Often, though not always, the application will run out of ROM on a microprocessor. This, in comparison to a desktop computer, which is a general-purpose processor and support system designed for a wide range of applications. The range of embedded software is much broader than desktop software, where a handful of applications (word processors, spreadsheets, games, and so on) make up the vast majority of applications.
Embedded tools are now catching up with Windows GUI, object oriented programming and client/server architectures. These new tools are stressing ease-of-use and enabling team disciplines to work on the same project from different locations across the enterprise.
Driving this need for tools is a basic fact of the embedded market. With increased competition, companies supplying embedded products cannot afford schedule slippage that result in missed market opportunities. Increasing the productivity of engineers and programmers has become the critical factor in bringing embedded products to market quickly and at reasonable cost.
The most developed segment of the embedded tools market are the off-the-shelf real-time operating systems (RTOSs), including their support programming tools: source level debuggers, integrated development environment, and compilers.
The commercial RTOS market is highly fragmented with offerings from dozens of vendors, supplying products for many different microprocessors. This fragmentation is caused by three factors. First, there are dozens of different microprocessors optimized for different embedded applications. A different version of the RTOS, with a corresponding set of development tools, must be written for each microprocessor. Second, different applications offer widely variable sets of available programming resources. Some RTOSs are optimized for more resource constrained environments, and others are aimed at less constrained environments. And third, different end market applications have different needs and levels of complexity. Some RTOSs offer a wide range of available services, while others are simpler. A single RTOS cannot provide the optimal solution for every application.
COMPONENTS NEEDED:
The components needed for the development of Embedded Applications are:
1. Micro Controller.
2. Real-time Operating System.
3. A language for coding.
4. Machine code generator.
5. Debugger.
Micro Controller:
The micro controller consists of microprocessor, ROM, RAM and some I/O ports all on the same chip. The commonly used micro controller is 8051.
Machine code generator:
The source code is written in a particular language like C/C++. This has to be then used to generate the code for the particular microprocessor. The machine specific code is then burnt into the chip(ROM). The microprocessor takes the instructions from the ROM and executes them to produce the desired effect.
CHAPTER 4
REAL-TIME OPERATING SYSTEM
What does real-time mean when used in the context of an operating system? Simply put, this means that the embedded application can and will respond to external events in real time, as opposed to waiting for some other task or process to complete its operation. This is made even more confusing by the use of the terms hard real-time and soft real-time.
Hard real-time means an activity must be completed always by a specified deadline (which may be a particular time or time interval, or at the arrival of some event), usually in tens of microseconds to few milliseconds. Some examples include the processing of a video stream, the firing of spark plugs in an automobile engine, or the processing of echoes in a Doppler radar.
Soft real-time applies to those systems that are not hard real-time, but some sort of timeliness is implied. That is, missing the deadline will not compromise the systemâ„¢s integrity, but will have a deleterious effect. Examples of this type of system are point of sale (POS) systems in retail stores, ATMs and other credit card machines, and PDAs. When a POS system can not read the bar code because the item was scanned too quickly, the system simply indicates an error, and the item will be scanned again for identification.
Further confusing the notion of hard and soft real-time is increased processor speeds. When the processor speed increases, interrupts are processed more quickly. More importantly, the interrupt window in which interrupts are disabled keeps shrinking and this will improve the timeliness of response. So soft real-time performance may improve just as a function of processor speed. But countering this trend is the increasing complexity of the applications, requiring more processing to be done at interrupts, and the blurring of the hardware-software interface.
But be they hard or soft, real-time (or perhaps a general term should be embedded) OSs have four characteristics in common that differentiate them from desktop or mainframe OSs.
Bounded Interrupt Servicing:
There is a maximum allowable time that the system can be diverted to process an interrupt. The interrupt service routine must do the absolute minimum processing and terminate.
Priority Based Scheduling:
In a real-time system, all tasks are assigned a level of priority, viz a viz each other. This priority may be based on any number of criteria (including run time). This implies that tasks do not execute just because they are ready, but rather because they are the highest priority task that is ready.
Preemptive Tasks:
All tasks and routines must be constructed in such a way that they can be pre-empted by some higher priority task or routine becoming ready.
Scalability:
The OS services provided are not monolithic. Rather, they are provided as a set of modules or libraries. The services needed for an application are included in the build by simply setting flags at the time of the application build; or, in the case of libraries, by having the linker pull in the services used by the application; or by using conditional compilation to scale the OS.
But, besides these four, there are other differences between real-time and desktop OSs that have more to do with the needs of the end application, the needs of the embedded developer, and the restrictions placed on the application by the resources available. The most obvious is the RAM requirement. Considering the volumes and tight end user pricing of most embedded systems, RAM is a very precious commodity. The OS must use this memory efficiently while preventing fragmentation, recovering RAM when tasks are terminated, requiring the minimum amount of RAM when tasks are created, and providing for efficient stack and heap structures.
Probably just as important are the scheduling algorithms, since these are at the heart of system performance. There are wide varieties of algorithms that have been developed and, depending on the end application, the developer would want to choose the one satisfying the response requirements while being the stingiest on resources. Some of the algorithms developed include:
Heuristic:
At any time, the task with the earliest deadline will be executed. This algorithm is efficient, but it may not find a feasible schedule even if one exists.
Round Robin:
Each task is assigned a fixed amount of processor time, and when that time is up, the next task executes.
Simple Priority:
The user assigns a priority at the time of thread creation. The next thread to execute is based on the priority of the ready thread. In a large system, it can be difficult for the user to decide the priorities of each thread.
Rate Monotonic:
The tasks of the program are assigned priorities in descending order according to the length of the period. The task with the shortest period has the highest priority, and the task with the longest period has the lowest priority. In its simplest form, it does not provide support for sporadic events. Modifications have been proposed, such as polling, priority exchange algorithm, and deferrable server algorithm.
Deadline Monotonic Scheduling:
This is close to the Rate Monotonic but accommodates sporadic tasks.
Not as obvious, but just as important, are mechanisms that have been created to synchronize and communicate between tasks. While also found in non-RTOSs, these mechanisms take on a critical role in embedded systems due to the requirements on response and the scarcity of resources. The well known synchronization mechanisms are semaphores, mutexes, and condition variables, with message queues and mailboxes being
among the more common task communication devices. But just having these mechanisms is not sufficient. These mechanisms must be designed in such a way as to take a bounded amount of time for worst case situations. For example, if a set of tasks have to wait for a semaphore in a wait queue, the wait queue should not be singularly linked, since removing a task from the list will require traversing the entire list of waiting tasks. Some more efficient algorithm, with bounded worst case performance, must be used.
An example of a commercial RTOS architecture is given in Figure 1 for pSOSystem from Integrated Systems, Inc.
pSOSystem uses a modular architecture, containing the pSOS+ real-time, multi-tasking kernel and a collection of companion software components and libraries. These components are delivered as black boxes, remaining unchanged from application to application. This assures high reliability to the end user.
Example structure of an embedded system
CHAPTER 5
DESIGN ISSUES FOR EMBEDDED SYSTEMS:
Embedded Systems are, if nothing else, characterized by constraints such as response, size, performance, costs, and so on. And it is optimizing for these constraints (or rather perhaps working within them) that makes designing an embedded system a difficult task. Numerous questions have to be answered before the design even begins:
? What are the worst case performance requirements for each activity?
? What are the number and complexity of activities to be performed?
? How should these activities be distributed amongst the software tasks so that the processor load is balanced (and thereby get the best cost/performance out of the processor selection)?
? What is the degree of coupling of these tasks (critical deadlines, type of data flow among tasks, event interdependencies)?
? How much RAM and ROM does the hardware design provide?
? How much RAM and ROM will be consumed for the specific set of tasks, ISRs, queues, and so on?
? How much buffer space should be allocated for stack usage?
Over the years, the articles in Embedded Systems Programming magazine have dealt with many, if not most, of the issues facing embedded systems designers. A number of the more commonly faced issues are summarized here.
Time Constraints:
Real-time operating systems bow to a combination of time specific constraints. Some routines must execute at precisely fixed intervals, while other routines are not bound to a critical time alignment. The most critical task of an embedded programmer is to characterize each of the actions to be performed so he will know how to assign priority and resources to that action in order that the overall system performance objectives are met. To aid in this task, it is helpful to break the actions in an embedded system down into the following four task groups:
1. Time critical task routines are those that must occur at a fixed rate with a minimum startup latency (e.g., servicing an A/D converter).
2. Time sensitive task routines are different from time critical tasks in that they can tolerate a large latency before being serviced. Like time critical task routines, they may also occur at fixed rates or they may be initiated at random intervals, but are guaranteed to execute no more frequently than some fixed rate by the task handler itself.
3. Idle task routines are important background operations, and they execute as frequently as possible?at more or less random interval when it is convenient.
4. Mainline tasks routines interpret the user commands, perform non-real-time functions, and make calls to the time sensitive and idle task service routines.
Safety:
While the reliability of hardware has improved dramatically, when the mission of the embedded system is critical, the embedded designer must build tests of the processor and memory into the application. There are a variety of ways that this can be accomplished.
Probably the first and simplest safety technique learned by many embedded programmers consists of filling unused program memory with either halt instructions or illegal instructions. This technique guards against illegal jumps outside of the program space and provides cheap insurance.
Another common protection is to use buffers that guard against stack underflow/overflow or the corruption of a task's stack. Many of the commercial RTOSs now contain facilities and functions that support stack checking.
To verify the integrity of a program or data stored in ROM, a simple ROM test should be included as well a watchdog timer to prevent the software from getting caught in a loop.
It is also well known that a rogue pointer, for example, can lead to wholesale corruption of memory. So how does one protect against the corruption of program data? One technique is the redundant storage of critical variables, and comparison prior to being used. Another is the grouping of critical variables together and keeping a CRC over each group.
Device Drivers:
It is well known that writing efficient device drivers requires knowledge of both hardware and software. The resulting device drivers become the keys to embedded system performance since they are called repeatedly, and therefore dictate real-time performance in terms of response time, and utilization of memory and other system resources.
Interrupt Service Routines:
Using interrupt processing is a powerful technique that is often more appropriate than using software loops to continuously poll peripheral devices. However, the compiler does not dictate interrupt-processing strategy, and most RISC processors do very little in response to interrupts. These constraints place a burden on the embedded developer in that he must decide which interrupt architecture is best. Some approaches are to save the interrupted context on a memory stack. Another is to preserve the context in a cache, be it on-chip registers (if there are a lot of them to use) or off-chip memory. To simplify debugging, it is best to keep ISRs short.
Storage Allocation:
One important feature to be considered in the selection of an RTOS or embedded system design is storage allocation. Ill-designed dynamic storage allocation can be wasteful for two reasons. First, allocating memory from the heap can be both slow and non-deterministic. The time it takes for the memory manager to search the free-list for a block of the right size may not be bounded. Second, one may create the possibility of a memory allocation fault caused by a fragmented heap. One typical solution is to statically declare all objects up front and get rid of dynamic allocation. However, this can waste storage since the objects always exist and take space. Whilst difficult, the apparently conflicting goals of a dynamic storage allocator can be achieved.
Optimizing Performance:
Writing embedded code that runs efficiently brings about a whole new set of rules. Often optimizing for speed and size opposing design goals-an improvement on one often degrades the other. In trying to achieve this balance, the article promotes the use of three techniques:
? the judicious use of the optimization options found with most embedded cross-platform compilers (for example, eliminating redundant code, or replacing operations with equivalent but faster operations, or unrolling loops, optimizing the use of registers, or removing code segments that the compiler knows cannot be reached)
? the mix of fixed and floating-point operations and
? the employment of user optimizations, making the most out of available resources.
Debugging Memory Problems:
Since many RTOSs and/or embedded microprocessors do not support memory protection, tracking down software memory bugs can become a serious debugging problem. In attacking this problem, it is best to categorize the problem by the type of Memory affected. In general, they fall into three categories:
? Global memory bugs: those bugs that result in corruption of global memory data areas.
? Stack memory bugs: these often cause a complete failure of the program execution; they are the hardest to track down as they are often a function of external events and the current state of the stack.
? Dynamically allocated memory bugs: examples are, heap memory allocated by a malloc service; or problems caused by writing past the boundaries of an allocated memory block or using one that is no longer allocated.
CHAPTER 6
GETTING THE EMBEDDED SOFTWARE INTO THE
TARGET SYSTEM
The locator will build a file that describes the image of the target softaware. Let us see the issue of getting that file into the target system.
PROM programmers
The classical way to get the software from the locator file into the target system is to create a RAM or PROM . Creating ROM is appropriate only when software development has been completed,since the toolong cost to build ROMs is quite high.
Putting the program into a PROM requires a device called a PROM programmer. This is appropriate ifvolumes are not large enough to justify using a ROM, if plan to make changes to the software, or while we are debugging . If we plan to use PROMs and a PROM programmer for debugging purposes,it is usefulto build the version of the taaget system in which the PROM is placed in a socket on the target system rather than being soldered directly into the circuit. Then when we find a bug, we can remove the PROM containing the software with the bug from the target system and put it into the eraser or into the waste baket ,program a new PROM with software that has the bug fixed, and put that PROm into the socket. Schematic view of socket
ROM emulator
Rom emulator is a device that replaces the ROM in the target system. From the point of view of the rest of the hardware in the target system, the emulator looks just like a ROM. However, the ROM emulator contains a large box of electronics and a serial port or a network connection through which it can be connected to our host. Software running on host send files created by the locator to the ROM emulator , which will act like a ROM that has been programmed with the software we have written.
CHAPTER 7
FUTURE TRENDS IN EMBEDDED SYSTEM RTOS
There is a flood of trends rushing through the embedded market today, many influencing the RTOS requirements in conflicting ways. It is hard to envision that five years from now RTOS products will bear much resemblance to what is supplied today.
Some of these trends are application driven while others are device driven, and it is important to understand the influences these trends will have.
Application Specific:
In several markets, the end users have banded together to issue specific requirements for RTOSs to be used in their future products. They have purposely chosen to drop their proprietary behaviors of the past in order to get the benefits of multiple suppliers and interoperability of software. In this manner, only the needed software is linked into the application, preventing additional overhead and allowing for an extremely efficient kernel implementation.
System On A Chip (SOC):
As mentioned earlier, SOCs are beginning to appear throughout the embedded market, in at least three different ways. First, the semiconductor suppliers are providing developers the ability to pick and choose from a combination of industry standard functions integrated around a 32-bit core processor. These functions may include memory, IO drivers, a bus interface, network protocol support, or algorithms for special functions, such as an MPEG decoder. Second, end product manufacturers are integrating custom ASICs with common 32-bit core processors to provide complete solutions. Some recent examples include cable modems and ATM switches. And third, startups are emerging that will provide custom design services, complete with optimized RTOS, compiler, and debuggers.
SOC will be particularly well suited for a whole range of consumer electronics and wireless communications devices where size, cost, and low power requirements are crucial. It will also drive cost reductions in networking and telecom equipment, where more functionality can be added at lower costs. A subset of this SOC trend is the emergence of multi-core devices on single silicon. The most common to date has been the combination of standard microprocessors and Digital Signal Processors (DSPs). In some cases, the DSPs are dedicated function processors, but emerging trends have the DSP as a full programmable device.
Automatic Code Generation:
Probably the most radical notion is the idea that application code can be generated automatically from graphical diagrams depicting the logic flow for the end product. To a limited extent, this has already been accomplished, with products like MATRIX, BetterStat, Statemat, and MATLAB?being used for application modeling and code generation. In the case of MATRIX, flight ready code for the international space station has been used for some time now, and the technology is being extended into the more restrictive automotive market. If these tools were to become reality, the whole notion of commercial RTOS and development tools will be upset, as the developer will only interact with the graphical tool, and will be totally isolated from the resulting software implementation.
CONCLUSION:
This seminar helped in understanding the following concepts.
1. Embedded systems application development.
2. The components of embedded systems.
3. The design issues.
4. The applications in which embedded systems are used.
5. RTOS and its features.
6. How to carry out effective presentation.
REFERENCES:
1. WWW.EN.WIKIPEDIA.COM
2. WWW.EMBEDDED .COM
3. TECHNICAL INFORMATION FROM INTEGRATED SYSTEMS INC.

[attachment=4273]
EMBEDDED SYSTEMS

---

G.B.K.CHAITANYA,
III YEAR,

A.BRAMARAMBIKA
B.E. III YEAR, B.E.

---

abstract

Now a days consumer products like washing machine, microwave oven, and cellphone
to industries digital technology plays a major role. But we have not yet used this
technology in bikes. What my idea of making u se of this tech. in bikes is a complete
digital bike operating system sans key. According to my invention key is not required
to operate a bike(The operation includes starting & locking the bike, fuel tank cap
opening) & also the petrol knob need no t to be turned on for petrol flow. All are done
automatically by pressing a single button. To start the bike a four -digit password has to
be entered. A keypad is provided for this purpose. After the acceptance of the
password, we can operate the bike . Some safety features are also introduced .If others
try to operate the bike with out the permission from the bike owner they will fail in
their attempt and immediately an alarm which is fixed in the bike starts louding and at
the same time a receiver will indicate it to us.

[attachment=5270]
EMBEDDED SYSTEMS full report

S. Ramesh

---

ABSTRACT

Many embedded systems have substantially different design constraints than desktop computing applications. No single characterization applies to the diverse spectrum of embedded systems. However, some combination of cost pressure, long life-cycle, real¬-time requirements, reliability requirements, and design culture dysfunction can make it difficult to be successful applying traditional computer design methodologies and tools to embedded applications. Embedded systems in many cases must be optimized for life-cycle and business-driven factors rather than for maximum computing throughput. There is currently little tool support for expanding embedded computer design to the scope of holistic embedded system design. However, knowing the strengths and weaknesses of current approaches can set expectations appropriately, identify risk areas to tool adopters, and suggest ways in which tool builders can meet industrial needs.
INTRODUCTION:
If we look around us, today we see numerous appliances which we use daily, be it our refrigerator , the microwave oven, cars, PDAs etc. Most appliances today are powered by something beneath the sheath that makes them do what they do. These are tiny microprocessors, which respond to various keystrokes or inputs. These tiny microprocessors, working on basic assembly languages, are the heart of the appliances. We call them embedded systems. Of all the semiconductor industries, the embedded systems market place is the most conservative, and engineering decisions here usually lean towards established, low risk solutions. Welcome to the world of embedded systems, of computers that will not look like computers and wonâ„¢t function like any thing we are familiar with.
As the name signifies, an Ëœembedded systemâ„¢ is built into a noncomputing device, say a car, TV or toy. We can define an embedded system as a computing device, built in to a device that is not a computer, and meant for doing specific computing tasks. In general engineering terms, embedded systems are used for the control of industrial or physical processes. In computer science terms, embedded systems are distributed reactive systems. Typically these systems have to react to stimuli from their environment in real time. This can be of high importance in situations where a lot of signal processing must be carried out on the inputs inorder to compute the outputs. e.g., multimedia applications.
Embedded systems have been around us for about as long as computer themselves. These were first used in the late 1960s to control electro mechanical telephone switches. As computer industry has moved towards smaller systems over the last decade or so, embedded systems have also moved along with this trend.
Classification:
Embedded systems are divided into autonomous, realtime, networked & mobile categories.
Autonomous systems: They function in standalone mode. Many embedded systems used for process control in manufacturing units& automobiles fall under this category.
Realtime embedded systems: These are required to carry out specific tasks in a specified amount of time. These systems are extensively used to carryout time critical tasks in process control.
Networked embedded systems: They monitor plant parameters such as temperature, pressure and humidity and send the data over the network to a centralized system for on line monitoring.
Mobile gadgets: Mobile gadgets need to store databases locally in their memory. These gadgets imbibe powerful computing & communication capabilities to perform realtime as well as nonrealtime tasks and handle multimedia applications.

Reference: http://studentbank.in/report-embedded-sy...z11bgNhDvH

[attachment=5317]

---

This article is presented by:
Ketul B Sutaria
Siddarth P Vaidya

The Embedded Systems

WHAT ARE EMBEDDED SYSTEMS?

Introduction
In the fast growing world there always arise a need for a product that are smaller, cheaper & smarter.
With the increasing amount of the salaries to be paid for small work is not a practical solution to deal with.
Thus there arise the need for a machine, which can work autonomously & requires very less attention to be paid.
All these need lead to the invention of the technology that is known as embedded system.


Definition

These are the complicated systems that are the combination of a hardware & software.

An embedded system is preprogrammed to perform a narrow range of functions with minimal end user or operator intervention.

It refers to a device that contains computer logic on a chip inside it not independently programmable by the user. Such equipment is electrical or battery powered. The chip controls one or more functions of the equipment, such as remembering how long it has been since the device last received maintenance.

With the combination of the hardware & software make them performs or controls a function, either in whole or in part, as an integral element of a larger system or subsystem such as, ground support equipment, flight simulators, engine test stands, or fire control systems.

The addition of the mechanical element also proves to be useful as it helping developing a complete low power operated system.
E.g. As an anti-lock braking system in a car.

These systems are mainly produced in order to achieve specific purpose & allow themselves to make the decision in different conditions.

With all these things they are able to do the prescribed work to them with efficiency.
Now continuously working, they consume power. Also the complicated technologies converging in them, they prove to become costly. But this is the main criterion they are to be designed.
Today they have proved not only to be reliable but also to be cheaper then we have imagined.
A specialized computer, often hidden from the end user, used to control devices such as automobiles, home and office appliances, hand-held units of all kinds as well as machines as sophisticated as space vehicles. Operating system and application functions are often combined in the same program. An embedded system implies a fixed set of functions programmed into a non-volatile memory (ROM, flash memory, etc.) in contrast to a general-purpose computing machine. Think of it like a self-contained system. An example would be a computer in a car that controls the ignition system. Because they often operate critically important applications, reliable real-time reactions are vital.

"Real Time" Systems such as industrial control, security, facilities automation, navigational systems, production control, laboratory instrumentation, and similar microprocessor-controlled devices. Embedded systems tend to serve no other function independent of the system into which they are embedded, although some include external data input/output linkages that may pass date-sensitive data to other systems. Operating systems, bootstraps and other pre-programmed instructions are often contained on EPROM or EEPROM

[attachment=5360]
EMBEDDED SYSTEMS full report

Babak Kia
Adjunct Professor
Boston University
College of Engineering
Email: bkia -at- bu.edu

---

Microcontrollers

sufficientcomputer on a chip, used to control devices

[attachment=5385]

---

EMBEDDED DATABASE TECHOLOGY
FOR SECURITY SYSTEMS

Security systems
whether pure software or a combination of hardware and software – must store and manage critical information reliably. Because these systems are a crucial part of the security infrastructure for enterprises, they have unusual requirements not common to many business applications that use database technology. Choosing the right database product can increase reliability, improve performance and enhance the level of security provided by mission-critical deployed systems.

Securing Data from Attack
Security infrastructure, just like other applications, operates on data – user passwords, profile and preferences, roles and responsibilities, access logs, configuration settings and more. Unlike many business applications, though, security infrastructure products must be hardened against attack. As a result, the components that make up the security software, including any database system, must be designed for secure deployment. Security threats can come from a number of implementation choices in software. Especially common, though, are threats due to exposed administrative or user-level interfaces, which allow an attacker to communicate directly with a subsystem in the security product. Many database systems rely on such interfaces in normal operation.
Designers of security infrastructure are often best served by choosing a truly embeddable database management system, rather than a conventional RDBMS designed for business applications, for use in their products. A commercial embedded database can provide all the performance, reliability and recoverability guarantees that applications require, and can also improve overall security by eliminating interfaces that could be use to compromise the system.
Oracle’s family of embedded database products, including Oracle Database, Oracle TimesTen In-Memory Database, Oracle Berkeley DB and Oracle Database Lite, was designed for use in applications that need fast, reliable storage services, without requiring a database administrator. These products can be deployed for zero or near zero administration, so that they are invisible and inaccessible to users and malicious attackers.

---

Submitted by
Vijay kumar. S
Vamsi kali Krishna. S

---

[attachment=6337]

---

Abstract

Imagine you control all the systems around just by a simple gesture and the things respond to you as if it was some magic. This could be possible with embedded systems.

The term ‘embedded systems’ is quite a complex one. Simply put, it is a combination of hardware and software that performs the component of a larger system. A few years ago embedded technology existed in stand-alone devices such as vending machines and copiers that did their jobs with little regards for what went on around them. But as technology advance to connect devices to the internet and to each other, the potential of embedded technology has increased. Home appliances, mobile phones, cars, tiny micro chips, avionics etc.., are all using embedded technology.

As you go about the affair of living, you put your life safe and luxurious with all the available resources .Now days we all are entrenched with computers and almost all depended on them. Devices with intelligence rule the world. Imbibing intelligence to these devices is through a system called “EMBEDDED SYSTEM”. Its applications provide marvelous opportunities for ingenious use of computer technology. Almost all every system introduced into the market is an example of Embedded System. An embedded device finds applications in all segments of industrial and commercial marketplace. Home appliances, mobile phones, Personal Digital Assistants (PDA), cars, tiny microchips and avionics are all using embedded technology.

The current topic “Automation of car” that we are going to present is one of the fine examples of Embedded System.

[attachment=6649]
Embedded Systems


INTRODUCTION

1.1 What is Embedded Systems?
Consider some real-world examples. Firstly, the case of an Intelligent Water-Level Controller For this, some sensors (MEMS based) is placed in the water tank, for level detection. The electrical outputs of the sensor are handled by an embedded login circuit. This circuit takes its own decisions for controlling the water pump. If the water level decreases from a certain level, the login circuit automatically turns-on the pump. In the same manner, if the logic circuit automatically turns-on the pump. In the same manner, if the water level increases from a certain level, it automatically turns-off the pump. Digital Soldering Station is another case, in which an embedded logic circuit controls the header for providing a constant temperature at the tip, by constantly detecting the tip temperature. In contrast to a manual gear system, an automatic gear system automatically changes gear levels according to vehicles’ speed conditions. A smart TV automatically adjusts picture quality according to ambient brightness conditions, through a photo sensor and an embedded circuit.
From above discussion we can conclude that, Embedded Systems are small systems embedded or hidden within a large system like TV Receiver. These small systems take big decisions also.

[attachment=6806]
EMBEDDED SYSTEMS full report


Power Source
1. System own supply with separate
supply rails for IOs, clock, basic
processor and memory and analog
units, or
2. Supply from a system to which the
embedded system interfaces, for
example in a network card, or
3 .Charge pump concept used in a
system of little power needs, for
examples, in the mouse or contact-less
smart card.

---

[attachment=7642]


ABSTRACT

“Thousands of persons killed as a cause of earthquake”. The above words aren’t the headlines of the newspaper but daily news everyone come across whenever we go through a newspaper or watching over a TV news.

A person’s life is precious and meaningful to his loved ones.

We, as responsible Engineers felt a part of society to bring a system to avoid these mishaps. With the meteoric Embedded systems along with microprocessor our designed system in preventing deaths and providing safe guided measures.

A new revolutionary microwave life detection system, which is used to locate human beings buried under earthquake rubble, has been designed. This system operating at certain frequency can remotely detect the breathing and heartbeat signals of human beings buried under earthquake rubble. By proper processing of these signals, the status of the person under trap can be easily judged. The entire process takes place within a few seconds as the system is controlled by a microprocessor (8085) or microcontroller unit.

By advent of this system the world death rate may decrease to greater extent as large percentage of death occur due to earthquake.

We welcome and wish you to a safe journey of this paper.

INTRODUCTION:
At present as we all know the need of the hour is to find an effective method for rescuing people buried under earthquake rubble (or) collapsed building. It has to be done before we experience another quake. Present methods for searching and rescuing victims buried (or) tapped under earthquake rubble are not effective. Taking all the factors in mind, a system, which will be really effective to solve the problem, has been designed.

PRINCIPLE OF OPERATION:
The basic principle is that when a microwave beam of certain frequency [L (or) S band (or) UHF band] is aimed at a portion of rubble (or) collapsed building under which a person has been trapped, the microwave beam can penetrate through the rubble to reach the person.
When the microwave beam focuses the person, the reflected wave from the person’s body will be modulated (or) changed by his/her movements, which include breathing and heartbeat. Simultaneously, reflected waves are also received from the collapsed structures.
So, if the reflected waves from the immovable debris are cancelled and the reflected wave from the person’s body is properly distinguished, the breathing and heartbeat signals can be detected.
By proper processing of these signals, the status of the person under trap can be easily judged. Thus a person under debris can be identified.


MAJOR COMPONENTS OF THE CIRCUIT:
The microwave life detection system has four major components. They are
1. A microwave circuit which generates, amplifies and distributes microwave signals to different microwave components.
2. A microwave controlled clutter cancellation system, which creates an optimal signal to cancel the clutter from the rubble.
3. A dual antenna system, which consists of two antennas, energized sequentially.
4. A laptop computer which controls the microprocessor and acts as the monitor for the output signal.

WORKING FREQUENCY:
The frequency of the microwave falls under two categories, depending on the type and nature of the collapsed building. They are
1. L (or) S band frequency say 1150 MHz
2. UHF band frequency say 450 MHz

Let us see the advantages and disadvantages of both the systems later.

CIRCUIT DESCRIPTION:
The circuit description is as follows:
Phase locked oscillator:
The phase locked oscillator generates a very stable electromagnetic wave say 1150 MHz with output power say 400mW.
Directional coupler 1 (10 dB):
This wave is then fed through a 10 dB directional coupler and a circulator before reaching a radio frequency switch, which energizes the dual antenna system. Also the ten dB directional coupler branches out one-tenth of the wave (40mW) which is then divided equally by a directional coupler 2 (3 dB).
Directional coupler 2 (3 dB):
One output of the 3 dB directional coupler 2 (20mW) drives the clutter cancellation unit. Other output (20mW) serves as a local reference signal for the double balanced mixer.
Antenna system:
The dual antenna system has two antennas, which are energized sequentially by an electronic switch. Each antenna acts separately.
Clutter cancellation system:
The clutter cancellation unit consists of
1. A digitally controlled phase shifter I
2. A fixed attenuator
3. A RF amplifier
4. A digitally controlled attenuator.

---

---

[attachment=7643]



Possible within few couples of years.

Real Time Operating System (RTOS) and Embedded system are the major technologies that played a major role in making the above fairly tales come true.


Defination of Embedded System

An embedded system is one that has computer hardware with software embedded in it as one of its most important component.
It is a dedicated computer based system for an application or product.
As its software usually embeds in ROM, it does not need secondary memories as in a computer.

---

---

[attachment=8479]


By,

D.GOWRI
II B.Tech , E.C.E.,
&
Y.SUJALA II B.Tech ,E.C.E.,
MEKAPATI RAJA MOHAN REDDY
INSTITUTE OF TECHNOLOGY AND SCIENCE
MeRITS,
UDAYAGIRI,
NELLORE(dt).



 ABSTRACT:
This paper attempts to investigate the approach of embedded systems. The embedded system is a combination of computer hardware, software and perhaps additional mechanical or other parts, designed to perform a specific function within a given time frame.

KEYWORDS:
Design of embedded systems, embedded software architectures, user interfaces.

 INTRODUCTION:
An embedded system is a special-purpose computer system built into a larger device .An embedded-system is typically required to meet very different requirements than a general-purpose personal computer Two major areas of differences are cost and power consumption. Since many embedded systems are produced in the tens of thousands to millions of units range, reducing cost is a major concern. Embedded systems often use a (relatively) slow processor and small memory size to minimize costs.
• Some of the attributes of the coming era:
1. The number of smart devices ( i.e., products with embedded operating systems inside ) will grow exponentially, reaching numbers in the billions.
2. The choice of CPU will be more a matter of cost than technology or a architecture
3. Nearly all devices will have connectivity, whether wired or wireless.
4. Most devices will have the ability to be upgraded or repaired remotely, by downloading new firmware or software.
Most devices will have specific rather than general-purpose functionality, so their users application software will be defined by the manufactures (rather than loaded by their).
This needs to, “minimize cost and maximize specialization”creates the opportunity for embedded systems.

 Paper Identification Number : SS-2.5
This peer reviewed paper has been published by the Pentagram Research Centre (p) limited. Responsibility of contents of this paper rests upon the authors and not upon pentagram research center (p) limited. Copies can be obtained from the company for a cost.
Embedded systems are becoming all pervasive. Every microwave has one. A cellular hand phone has two. A luxury Mercedes car has around 40. The latest Boeing 777-302,will have tens of dozens-we’re talking about the ubiquitous microprocessor chips and their associated peripheral devices.
To cite other examples, embedded software allows your washing machine to choose speed according to the type of cloth, gives thinking power to the microwave, acts like a music conductor in the car engine and pushes rocket launchers into space
The embedded system generally comprises topics like real time embedded digital signal processing, microprocessor architecture programming concepts; Real-time Operating System (QXN, RT Linux, V x Works); Micro controllers; Embedded Systems Programming Data Communication Networking, C concepts and linux among others.

 START UP:
All embedded systems have start-up code. Usually it disables interrupts, sets of up the electronics, tests the computer (RAM, CPU and software), and then starts the application code. Many embedded systems recover from short-term power failures by skipping the self-tests if the software can prove they were done recently. Restart times under a tenth of a second are common.
“Embedded systems’ has come to mean “micro-controller programming”. With the increasing proliferation of embedded systems, and advances in hardware and software technologies and the blurring of the boundary between them we need a more meaning-ful glimpse into this area. “Embedded systems’ addresses this need and brings out the issues in building modern-embedded systems.

 DESIGN OF EMBEDDED SYSTEMS
The electronics usually uses either a microprocessor or a microcontroller some large are old systems use general-purpose mainframe computers are mini computers. Embedded systems design is getting complex, requiring intimate knowledge of both the hardware and software worlds. Cramming all those chips in a square centimetre of silicon real estate is more an art then a science. Getting the software to work with limited memory is often a struggle. Designers embedded systems strive to improve performance, reliability and cost effectiveness. Hardware and software choices are simultaneously considered. This is called co-design.
The goal is to produce an efficient implementation that satisfies-performance and cost requirements on the design the entire system on a chip-the SOC approach. Information appliances can be fabricated from custom SOC silicon .This has been successful in designing cellular hand phones where the high volume usually dictate this design strategy.

 CHARACTERISTICS :
Two major areas of differences are cost and power consumption . Since many embedded systems are produced in the tens of thousands to millions of units range, reducing cost is a major concern. Embedded systems often use a (relatively) slow processor and small memory size to minimize costs.
The slowness is not just clock speed. The whole architecture of the computer is often intentionally simplified to lower costs.
For example embedded systems often use peripherals controlled by synchronous serial Interfaces, Which are ten to hundreds of times slower than comparable peripheral used in PCs. Programs on an embedded systems often must run with real time constrains with limited hard ware resources:
Often there is no disk drive, operating system , keyboard or screen. A flash drive may replace rotating media and a small keypad and LCD screen may be used instead of a PCs keyboard and screen.
Firmware is the name for software that is embedded in hardware devices, e.g. in one or more ROM memory IC chips .

 PLATFORM:
There are many different CPU architecture used in embedded designs.
This in contrast to the disk top computer marke-t, which as of this writing (2003) is to
limited just a few competing architectures , chieply intel’s x86,and the apple/Motorola/IBM power PC, used in the apple macintosh.
One common configuration for embedded system is the system on a chip, an application specific integrated circuit, for which the CPU was purchased as intellectual property to add to IC’s design.

 TOOLS:
Like a typical computer programmer, embedded system, designers use compiler, assembler and debbuger to develop an embedded system.
Those software tools can come from several sources:
Soft-ware companies that specialize in the embedded market. Ported from the GNU software development tolls. Some times, development tools for a personal computer can be used if the embedded process is a close relative to a common PC processors . Embedded system designers also use a few software tools rarely used by typical computer programmers.
Some designers keep a utility program to turn data files into codes, so that they can include any kind of data in a program.Most designers also have utility programs to add a check sum or CRC to a program, so it can check its program data before executing it.


OPERATING SYSTEM:
They often have no operating system or a specialized embedded operating system (often real time operating system), or the programmer is assigned to part one of these to the new system .

 EMBEDDED SOFTWARE ARCHITECTURES;
There are severally basical different types of software architectures in common use.

 THE CONTROL LOOP:
In this design, the software simply has a loop. The loop calls subroutines. Each subroutine manages apart of the hardware or software. Interrupts generally set flags, or update counters that are read by the rest of the software.
A simple API disables and enables interrupts. Done right, it handles nested calls in Nested subroutines, and restores the preceding interrupt state in the outer most enable. This is one of the simplest methods of creating an exokernel.
Typically, there’s some sort of subroutine in the loop to manage a list of software timers, using a periodic real time interrupt.
When a timer expire, an associated subroutine is run, or flag is set . Any expected hardware event should be backed-up with a software timer . Hardware events fail about ones in a trillion times.
That’s about once a year with modern hardware. With a million mass-produced devices, living out a software timer is a business disaster.
State machines are implemented with a function-pointer per state- machine (in C++, C or assembly any way). A change of state stores a different function into the pointer. The function pointer is executed every time the loop runs.
Many designers recommend reading each IO device once per loop, and storing the result so the logic acts on consistent values.
Any designers prefer to design their state machines to check only one are two things per states. Usually this is a hardware event, and a software timer .
Designers recommand the hierarchical state machines should run the lower-level state Machine before the higher, so the higher run with accurate information.
Complex function like internal combustion control are often handle with multi-dimensional tables.
Instead of complex calculations the code looks up the values. The software can interpolate between entries, to keep the table small and cheap. One major weakness of this system is that it does not guarantee a time to respond to any particular hardware event. Careful coding can easily assure that nothing disables interrupts for long.
Thus interrupt code can run at vary precise timings.Another major weakness of this system is that it can become complex to add few features. Algorithms that take along time to run must be carefully broken down so only a little piece gets done each time through the main loop.
This system’s strength is it’s simplicity, and on small pieces of software the loop is usually so fast that nobody cares that is not predictable.
Another advantage is that system guarantees that a software will run. There is no mysterious operating system to blame for bad behaviour.

 USER INTERFACES:

User interfaces for embedded systems vary wildly, and thus deserve some special comment. Designers recommend testing the user interface for usability at the earliest possible instant.
Exactly one person should approve the user interface ideally, this should be a customer, the major distributor or someone directly responsible for selling the system. The decision maker should be able to decide. The problem is that a committee will never make-up its mind, and neither will some people. Not doing in this causes avoidable, expensive delays. A usability test is more important then any number of opinions. A touch-screen or screen-edge buttons also minimize that types of user actions. Another basic trick is to minimize and simplify the type output.
Designs should consider using a status light for each interface plug, or failure condition ,to tell what failed. A cheap variation is to have two light bars with a printed matrix of errors that they select-the user can glue on the labels for the languages that she speaks.
For example, Boeing’s standard test interface is a button and some lights. When you press the button all the lights turn on. When you release the button the lights with failures say on. The labels are in basic english. For another example, look at a small computer printer. You might have one next to your computer. Notice that the lights are labeled with stick-on the labels that can be printed in any language. Really look at it.
Designers use colors. Red means the user can get hurt-think of blood.
Yellow means some thing might be wrong. Green means everything’s OK. Another essential trick is to make any modes absolutely clear on the user’s display.
An interface has modes, they must be reversible in an obvious way.
Most designers prefer the display to respond to the user. The display should change immediately after a user action. If the machine is going to do any thing, it should start within 7 seconds, or give progress reports. If a design needs a screen, many designers use plain text.


 APPLICATIONS OF EMBEDDED SYSTEM:
• . Automatic Teller Machine (ATM).
• . Cellular telephones and telephone switches.
• . Computer network Equipment , including router and fire wall.………
• . Computer Printer .
• . Disk drive .
• . Engine controller and antilock break controller for automobiles.
• . Home auto machine products, like thermostat sprinkler, and security monitoring . . systems.
• . Handheld Calculator.
• . Household appliance, including. Microwave oven ,washing machine ,television sets . . DVD players/recorders.
• . Inertial guidance system for air-craft and missile.
• . Medical Equipment.
• . Multi function Wristwatches.
• . Personal digital assistants.
• . Programmable logic control for industrial automation and monitoring.
• . Video game console.

 CONCLUSION:
In this paper we had tried to cover the fundamental principles of embedded systems used in modern digital instruments. In modern world the major problem with present desktop system is that they are very bulky in size to they cause severe problem in their decomposition. But as the embedded system does same task with smaller size made then vary useful for electronic instruments and many others. So it’s the most crucial thing which will become the heart of every electronic device in feature.

 REFERENCES:
1. http://bamboowebarticles/e/m/embedded system.html
2. http://oranetech

---

[attachment=8960]
Computing Optimal Schedules of Battery Usage in Embedded Systems
Abstract:
The use of mobile devices is often limited by the battery lifetime. Some devices have the option to connect an extra battery, or to use smart battery-packs with multiple cells to extend the lifetime. In these cases, scheduling the batteries or battery cells over the load to exploit the recovery properties of the batteries helps to extend the overall systems lifetime. Straightforward scheduling schemes, like round-robin or choosing the best battery available, already provide a big improvement compared to a sequential discharge of the batteries. In this paper, we compare these scheduling schemes with the optimal scheduling scheme produced with two different modeling approaches: an approach based on a priced-timed automation model (implemented and evaluated in), as well as an analytical approach (partly formulated as nonlinear optimization problem) for a slightly adapted scheduling problem. We show that in some cases the results of the simple scheduling schemes (round-robin, and best-first) are close to optimal. However, the optimal schedules, computed according to both methods, also clearly show that in a variety of scenarios, the simple schedules are far from optimal.

presented By:
Y.Sreenu
Ch.V.Raghavendra Kumar

---

[attachment=9561]
ABSTRACT
Imagine you control all the systems around just by a simple gesture and the things respond to you as if it was some magic. This could be possible with embedded systems.
The term ‘embedded systems’ is quite a complex one. Simply put, it is a combination of hardware and software that performs the component of a larger system. A few years ago embedded technology existed in stand alone devices such as vending machines and copiers that did their jobs with little regards for what went on around them. But as technology advance to connect devices to the internet and to each other, the potential of embedded technology has increased. Home appliances, mobile phones, cars, tiny micro chips, avionics etc.., are all using embedded technology.
High-profile embedded chips are scaleable, generate small amounts of heat, and consume less power. These are generally preferred for their speed, accuracy and reliability. As they are compact in size and ability to perform time-critical and task specific operators, embedded devices find application in all segments of industrial and commercial market places and home appliances.
In recent years,it became apparent that control systems as integral components of larger systems, should be developed and designed concurrently with mechanics, hydraulics, and electronics. It is important that engineers have a good understanding of the implications of software technology embedded into traditional engineering systems. Current machines consist of physical components providing the means and a control system employing those means to fulfill the machine’s function. Together, they build up the controlled machine, which can also be called an embedded system. . New innovative applications in different areas will make embedded systems as one of the fastest developing technology of the near future.
This paper deals with concepts and developments of embedded systems in control of machines and gives a general overview of the basic components of control systems, ranging from sensors to actuators.
Embedded Systems
An embedded system employs a combination of hardware & software (a “computational engine”) to perform a specific function; is part of a larger system that may not be a “computer”; works in a reactive and time-constrained i.e is real-time environment.
Software is used for providing features and flexibility
Hardware = {Processors, ASICs, Memory...} is used for performance (& sometimes security)
The term ’embedded system’ can be used for a wide range of applications and devices. A useful definition is not easy to formulate. Boasson mentioned one characteristic that applies to all embedded systems: Neither the computer system without the special environment in which it is embedded, nor the environment without the computer system has any significance in itself.
An embedded system employs a combination of hardware & software (a “computational engine”) to perform a specific function; is part of a larger system that may not be a “computer”; works in a reactive and time-constrained environment.
Basics of Embedded systems
An embedded systems typically comprises the hardware, embedded RTOS, device drivers, communication stacks and embedded application software.
Embedded hardware: The embedded hardware mainly consists of a microcontroller with various peripheral ICs. A fixed size volatile memory such as DRAM or SRAM and non volatile memory such as Flash or EPROM, connected to the microcontroller, are an integral part of the device. Depending on the targeted application of the device, the peripheral can include communication device such as serial controller, Ethernet controller, or a wireless communication controller and other application-specific ICs (ASICs). Many handheld devices these days also have sensors, actuators, keypads and graphical LCD screens as user interfaces.
The only way a embedded machine control system can get information about its surroundings, is through the use of sensors and/or sensor systems. Control signals from the embedded control are converted into power and/or movement through Actuators.
Sensors: During the past years a shift has taken place from mechanization towards automation. This implies the extensive use of sensors (and actuators) in order to be able to actually control (and influence) the actions that are performed by the controlled system.In principle the task of a sensor is fairly simple. It transforms an input signal that usually is difficult to handle in its original form to a more manageable form. Between input and output of the sensor a number of processes take place to obtain the desired result, as schematically shown in Figure.
Actuators: Actuators come in many forms and shapes. They act as the ’arms and legs’ of the machine. Actuators convert control signals into power and/or movement,as schematically shown in Figure below. Control signals do not have to be of electrical nature, also other kinds are possible. The power conversion can be done in a number of ways.
The most common energy sources for actuators are:
• Compressed air, pneumatics
• Pressured oil, hydraulics
• Electricity, electro mechanics
Embedded RTOS: The concept of real-time operating system (RTOS) is inseparable when we talk about embedded systems. All intelligent devices that perform complex functions have an embedded operating system inside. A real-time operating system (RTOS) is built for specific applications and guarantees response to an external event with in a specified time constraint. This operating system is typically real time in nature, i.e. it is capable of responding deterministically to time-critical external events.
For example, when you suddenly apply brakes for your car to avoid an accident, the ‘intelligent gad-get’ responds immediately. Imagine the plight of a driver if there is no response… the result is obvious

Presented by:
A.Alekya Raju
G.R.Kavya

---

[attachment=10964]
Abstract:
The technical Brilliance and Developments in different fields has led to a drastic change especially in the communication field. Devices with intelligence rule the world. Imbibing intelligence to these devices is through a system called “EMBEDDED SYSTEMS”. It is the evolution or further development of the computing system. Its applications provide marvelous opportunities for ingenious use of computer technology. Almost every new system introduced is an example of Embedded System. These systems are more intelligent and autonomous.
Embedded Systems are combinations of hardware and software that are mounted on compact electronic circuit boards integrated into devices. They are engineered or intended to perform one specific function in a specific environment. An important decision in the design of an embedded system is the selection of the processor(s) around which the rest of the system is to be built. It is a chip that contains a microprocessor, some memory & I/O interface circuitry useful in embedded applications and is often called an ‘EMBEDDED PROCESSOR’ or ‘MICRO CONTROLLER’ chips as they perform important control functions, and are based on micro controller.
The current topic “Automation of car” that we are going to present is one of the fine examples of Embedded System.
Autonomous car: There are many paradigm shifts taking place due to information explosion and the concept of autonomous vehicle is one shift. The car, which is embedded, can simulate the human driver completely and direct the vehicle on the road. Autonomous vehicle is the drastic change in technical brilliance and developments in different fields with EMBEDDED SYSTEM as pioneer.
Introduction:
The term embedded system is quite a complex one. Simply it is a combination of hardware and software that forms the component of a larger system, this in turn is programmed to perform a range of dedicated functions usually with a minimal operator intervention. In embedded systems the hardware is normally unique to a given application, computer chips are embedded into the control electronics to manage the products functionality.
Embedded systems are rapidly becoming a catalyst for change in computing data communications, telecommunications, industrial control and entertainment sectors. New innovative applications in these as well as other areas such as home networking and car infotainment will roll out in the near feature.
The fine art of automation:
We load the code of our destination in the dashboard computer and turn the car on, while we remain seated carefree on the rear seats. Then its all the job of the ‘unknown’ to drive it on the roads, bridges, thought the bazaars, past the crossings to the destination, without getting challenged even once for traffic rule violations.
A fully computerized car capable of doing almost every thing a car lover would want to. Almost all automobiles will interact with computer on dashboards. From ordering pizza to booking tickets at the nearest theatre, things would be as easy as giving orders to your servant. As a matter of fact, vehicles all over the world are now fitted with intelligent devices that make the vehicles to respond to various factors –be it climate control, sudden accelerations or braking or even self-repair of modules.
The finger print technologies have been introduced to enter and start your car with the touch of a finger. The fingerprint, which is acting as a key, would trigger a check of the mirrors, steering wheel, radio and temperature to ensure that they're the way you like them. The convenience of fingerprint recognition technology comes with heightened security. Unlike personal identification numbers, passwords and keys, each person's unique fingerprints can't be duplicated, lost or forgotten.
Description:
As stated above that a vehicle can run by itself with out the intervention of human beings by the embedded intelligence in it. For this purpose Global Positioning System (G.P.S) using satellites can provide positioning information and proves to be a versatile all-time. For still higher accuracy wide area differential GPS is used, which offers a robust system that readily deals with selective availability errors and satellite clock errors.
The models for GPS also include aiding sensors, e.g. dead reckoning, radar and camera. A computer is simply required to feed destination into a dashboard computer. Highly sensitive actuators simulate a human driver completely and direct the vehicle on the road. The vehicle transmitter broadcasts its position and velocity to other immediate participants for collision-avoidance and lane changing manoeuvres. Forward and reverse motions and u-turns are precisely achieved as per route guidance requirements. Furthermore, an accurate steering control is obtained using Pulse Code Modulation technique and acceleration/braking control is successfully implemented using learning adaptive system.
The reliability, efficiency and cost effectiveness of an autonomous vehicle depend mainly on how judiciously its navigation sensors, perception unit and computer control is incorporated.
The driver’s activity is influenced by several factors that depend on driver itself and is environment such as traffic density, traffic status, time of travel and weather. Thus the driving activity deals with a combined driver vehicle-environment system shown in figure
The vehicle is required to blend its environmental perception capabilities with its intelligent controls in order to affect optimal path-planning strategies that not only avoid obstacles but also minimize criteria such as time of travel, fuel consumption, exposure to pollution/danger, etc. however basic driving functions consists of lane-keeping, safe distance maintenance, timely lane changing and overtaking. The key to all these driving tasks is collision avoidance.
The Master Control Station (MCS) receives the positioning information from the satellite by employing WADGPS concept. The MCS is linked to GPS instrumented position location systems (PLS) installed on the autonomous vehicles through a data page link sub system (DLS). The DLS can either use VHF or UHF or L-band, incorporating time division multiple access protocol to handle on the roads. A block forward error correction code is employed to protect and maintain the message integrity.
The desired destination and starting position of the vehicle together with the time of travel, manifest an optimal route on the road network. Once the vehicle commences the journey the sensors continuously keep track of the direction and displacement of the vehicle initial calibration is a little crucial for dead reckoning performance; how ever a feed back calibration indicated in fig suggested to obtain distance accuracy better than 99.9 percent.
The new generation microprocessors promises further increase in system capabilities while simultaneously shrinking both volume and power consumption of the autonomous vehicle embedded system. The digital road maps, available on CD-ROM’s have substantially increased safety of automobiles. These maps along with GPS navigation provide a
Feasible solution to autonomous vehicle system. The expert system technologies are integrated with digital maps along with the CCD camera images, magnetic compass, and the GPS system, for obtaining a real time intelligent decision support navigation package. The integration of GPS and communication suggests an efficient transportation system for increasing the road traffic safety smooth driving without traffic jams and a comfortable driving environment. Further more the autonomous vehicle relies on such intelligent system integration that leads to complete collision free in time of real time situation.
The internal platform and rate gyro and accelerometer package keeps the vehicles central processing unit (CPU) well informed about the incremental changes in the vehicles parameters. The wheel odometers provide the vehicle traveling distances by multiplying the number of electronically generated pulses by a constant, depending upon wheels perimeter
The information concerning deviation from the road center is obtained by magnetic as well as optical sensors, and fed to the CPU. The GPS receiver updates the vehicles position and velocity to centimeter/decimeter levels as required for the lateral or longitudinal control actions. The autonomous vehicle embedded software mission finally yields the estimates for throttle and heading angle increments for a safe and accident free Manoeuvre. The following figure gives an indication of all the technologies used in a car
Advantages and comforts:
1. The adoptive cruise control ACC technology used in the cars from automobile makers keeps advancing to new levels of safety. In microwave radar unit there is a laser transceiver, fixed on the front of the car to determine the distance and relative speed of any vehicle in its path, which keeps safe distances from other vehicles on the busy roads. The driver can set the speed of his car and the distance between his and other cars. When traffic slows down vehicle speed is altered using moderate braking to maintain a constant distance between his and other cars.
2. In advanced systems just in the case the driver over speeds or suddenly falls over and guides the car to a safe halt. And if you have programmed it right, the GPS in the car would take you to your destination .so, right from brakes to automatic traction control to air bags and fuel-air mixture control, the intelligence takes over
3. A few advanced car prototypes with embedded systems have been tried and tested where even if a smart thief has managed to break in through the car, the car doesn’t start up even if it does the computer I the car would lock the steering wheel and cutoff the fuel injection supply … in the mean time a signal is set to the nearest police station and the owner informing them about the thief.
4. Some designs now include so-called "pre-safe" systems, which sense possible collisions in advance based on emergency braking, skidding, and sudden evasive maneuvers. They will prepare a car by automatically moving the front seat either backward or forward for the safest distance from the instrument panel, adjusting the seat belt for the correct tension, and even closing the sunroof in case of a potential rollover. The idea is to "cradle" the car's occupants for maximum safety.
Indian efforts in embedded system development: -
Our India too entered into the field of embedded systems and had great developments in this field. it got marvelous results in the field of “Telematics” which is a part of technology used in cars.
Total telematics experience is what they are looking for simply put telematics is the vehicles capability to communicate with the outside world and or the vehicle operator. It is a combination of telecommunication and computing
Mistral software, which was developed in India, has text-to-speech and speech recognition technologies to give the car occupants the ultimate comfort. So whenever there is a call on your mobile. You need not get jump at the very onset of the call. Relax the computer in the cars dashboard would do the job for you.
GPS navigation guides you through the traffic. The GPS interface in the car pinpoints your exact location on a map. In case the GPS signal cant be received due to high density of tall buildings or other magnetic interface, the ‘dead reckoning ‘ technique, which works for short durations guides you effectively. The system is also loaded with GSM/CDMA protocol standards further modified on the CANBUS standard t give uninterrupted information.
Another device called the array microphone cuts off the surrounding noise and allows the speaker to communicate effectively. The person at the other end hears the voice of the speaker without any out side interference.
Conclusion:
With the heights of the technology autonomous car is no more a myth. It’s a reality!
We would like to present that there must be further developments in this technology to make autonomous car more common all over the world. This can be happened by making the autonomous easy to operate for the user and the designers should concentrate more in producing autonomous cars, which should not cost a lot, they should in the vicinity of customers’ budget. With this type of vehicles there will be great advantages in the coming feature. Due to speed control technique, accident free driving is possible and fuel savage is also made possible by the technique, which will make the car to travel through shortest path. In the near future, autonomous car become more common all over the world. Indian efforts in the embedded technology can assure that these autonomous cars will become cheaper and may evolve with many more advantages. So that we could find ourselves using these autonomous cars in the near feature.

[attachment=11255]
INTRODUCTION TO EMBEDDED SYSTEM:
Embedded systems are electronic devices that incorporate microprocessors with in their implementations. The main purposes of the microprocessors are to simplify the system design and provide flexibility. Having a microprocessor in the device helps in removing the bugs, making modifications, or adding new features are only matter of rewriting the software that controls the device. Or in other words embedded computer systems are electronic systems that include a microcomputer to perform a specific dedicated application.
The computer is hidden inside these products. Embedded systems are ubiquitous. Every week millions of tiny computer chips come pouring out of factories finding their way into our everyday products.
Embedded systems are self-contained programs that are embedded within a piece of hardware. Whereas a regular computer has many different applications and software that can be applied to various tasks, embedded systems are usually set to a specific task that cannot be altered without physically manipulating the circuitry.
Another way to think of an embedded system is as a computer system that is created with optimal efficiency, thereby allowing it to complete specific functions as quickly as possible.
Embedded systems designers usually have a significant grasp of hardware technologies. They use specific programming languages and software to develop embedded systems and manipulate the equipment. When searching online, companies offer embedded systems development kits and other embedded systems tools for use by engineers and businesses.
Embedded systems technologies are usually fairly expensive due to the necessary development time and built in efficiencies, but they are also highly valued in specific industries. Smaller businesses may wish to hire a consultant to determine what sort of embedded systems will add value to their organization.
CHARACTERISTICS:
Two major areas of differences are cost and power consumption. Since many embedded systems are produced in tens of thousands to millions of units range, reducing cost is a major concern. Embedded systems often use a (relatively) slow processor and small memory size to minimize costs.
The slowness is not just clock speed. The whole architecture of the computer is often intentionally simplified to lower costs. For example, embedded systems often use peripherals controlled by synchronous serial interfaces, which are ten to hundreds of times slower than comparable peripherals used in PCs.
Programs on an embedded system often run with real-time constraints with limited hardware resources: often there is no disk drive, operating system, keyboard or screen. A flash drive may replace rotating media, and a small keypad and LCD screen may be used instead of a PC's keyboard and screen.
Firmware is the name for software that is embedded in hardware devices, e.g. in one or more ROM/Flash memory IC chips. Embedded systems are routinely expected to maintain 100% reliability while running continuously for long periods, sometimes measured in years. Firmware is usually developed and tested too much harsher requirements than is general-purpose software, which can usually be easily restarted if a problem occurs.
PLATFORM:
There are many different CPU architectures used in embedded designs. This in contrast to the desktop computer market which is limited to just a few competing architectures mainly the Intel/AMD x86 and the Apple/Motorola/IBM Power PC’s which are used in the Apple Macintosh.
One common configuration for embedded systems is the system on a chip, an application-specific integrated circuit, for which the CPU was purchased as intellectual property to add to the IC's design.
TOOLS:
Like a typical computer programmer, embedded system designers use compilers, assemblers and debuggers to develop an embedded system. Those software tools can come from several sources:
Software companies that specialize in the embedded market Ported from the GNU software development tools. Sometimes, development tools for a personal computer can be used if the embedded processor is a close relative to a common PC processor. Embedded system designers also use a few software tools rarely used by typical computer programmers.
Some designers keep a utility program to turn data files into code, so that they can include any kind of data in a program. Most designers also have utility programs to add a checksum or CRC to a program, so it can check its program data before executing it.
OPERATING SYSTEM:
They often have no operating system, or a specialized embedded operating system (often a real-time operating system), or the programmer is assigned to port one of these to the new system.
DEBUGGING:
Debugging is usually performed with an in-circuit emulator, or some type of debugger that can interrupt the micro controller’s internal microcode. The microcode interrupt lets the debugger operate in hardware in which only the CPU works. The CPU-based debugger can be used to test and debug the electronics of the computer from the viewpoint of the CPU.
Developers should insist on debugging which shows the high-level language, with breakpoints and single stepping, because these features are widely available. Also, developers should write and use simple logging facilities to debug sequences of real-time events. PC or mainframe programmers first encountering this sort of programming often become confused about design priorities and acceptable methods. Mentoring, code-reviews and ego less programming are recommended.
DESIGN OF EMBEDDED SYSTEMS:
The electronics usually uses either a microprocessor or a microcontroller. Some large or old systems use general-purpose mainframes computers or minicomputers.
START-UP:
All embedded systems have start-up code. Usually it disables interrupts, sets up the electronics, tests the computer (RAM, CPU and software), and then starts the application code. Many embedded systems recover from short-term power failures by restarting (without recent self-tests). Restart times under a tenth of a second are common.
Many designers have found one of more hardware plus software-controlled LED’s useful to indicate errors during development (and in some instances, after product release, to produce troubleshooting diagnostics)
A common scheme is to have the electronics turn off the LED(s) at reset, whereupon the software turns it on at the first opportunity, to prove that the hardware and start-up software have performed their job so far. After that, the software blinks the LED(s) or sets up light patterns during normal operation, to indicate program execution progress and/or errors. This serves to reassure most technicians/engineers and some users.
THE CONTROL LOOP:
In this design, the software has a loop. The loop calls subroutines. Each subroutine manages a part of the hardware or software. Interrupts generally set flags, or update counters that are read by the rest of the software.
A simple API disables and enables interrupts. Done right, it handles nested calls in nested subroutines, and restores the preceding interrupt state in the outermost enable. This is one of the simplest methods of creating an exocrine.
Typically, there's some sort of subroutine in the loop to manage a list of software timers, using a periodic real time interrupt. When a timer expires, an associated subroutine is run, or flag is set. Any expected hardware event should be backed-up with a software timer. Hardware events fail about once in a trillion times.
State machines may be implemented with a function-pointer per state-machine (in C++, C or assembly, anyway). A change of state stores a different function into the pointer. The function pointer is executed every time the loop runs.
Many designers recommend reading each IO device once per loop, and storing the result so the logic acts on consistent values. Many designers prefer to design their state machines to check only one or two things per state. Usually this is a hardware event, and a software timer. Designers recommend that hierarchical state machines should run the lower-level state machines before the higher, so the higher run with accurate information.
Complex functions like internal combustion controls are often handled with multi-dimensional tables. Instead of complex calculations, the code looks up the values. The software can interpolate between entries, to keep the tables small and cheap.
One major disadvantage of this system is that it does not guarantee a time to respond to any particular hardware event. Careful coding can easily assure that nothing disables interrupts for long. Thus interrupt code can run at very precise timings. Another major weakness of this system is that it can become complex to add new features. Algorithms that take a long time to run must be carefully broken down so only a little piece gets done each time through the main loop.
This system's strength is its simplicity, and on small pieces of software the loop is usually so fast that nobody cares that it is not predictable. Another advantage is that this system guarantees that the software will run. There is no mysterious operating system to blame for bad behavior.

[attachment=12277]
INTRODUCTION
Computers have evolved from few, huge mainframes shared by many people, and mini computers that were smaller but still shared to today’s PCs—millions in number, miniscule in size compared to the mainframes, and used by only one person at a time. The next generation could be invisible, with billions being around and each of us using more than one at a time. Welcome to the world of embedded systems, of computers that will not look like computers and won’t function like anything we’re familiar with
WHAT IS AN EMBEDDED SYSTEM?
As the name signifies, an embedded system is ‘embedded’ or built into something else, which is a non-computing device, say a car, TV, or toy. Unlike a PC, an embedded computer in a non-computing device will have a very specific function, say control a car, or display Web pages on a TV screen. So, it need not have all the functionality and hence all the components that a PC has. Similarly, the operating system and applications need not perform all the tasks that their counterparts from the PC sphere are expected to.
In short, we can define an embedded system as a computing device, built into a device that is not a computer, and meant for doing specific computing tasks. These computing tasks could range from acquiring or transferring data about the work done by the mother device to displaying information or controlling the mother device. Embedded systems could thus enable us to build intelligent machines.
Embedded systems is not a new and exotic topic that is still confined to research theses. There are many live examples of embedded systems around us. MP3 players (computing capability built into a music system), PDAs (computing in what essentially is an organizer), car-control systems, and intelligent toys are but a few examples of such systems already in place.
A typical embedded system consists of hardware (typically VLSI or very large-scale integrated circuits) specifically built for the purpose, an embedded operating system, and the specific application or applicatiospecification is considered to be an extension of the ISA bus specification. The PC /104 standard has since been extended to PC/104-plus to include the PCI bus. So, today you have PC-based embedded systems that have the ISA bus, the PCI bus, or both.
Unlike with regular PCs, in the world of the embedded PC, 386s, 486s and Pentiums are still good enough. Besides these, there are a number of CPUs meant specifically for embedded applications, like the StrongArm and the MIPS.
With embedded PCs you can even go beyond the single-function definition of an embedded system, and could build an entire PC into another machine; a PC inside a refrigerator, or a PC inside a car, for instance.
HARDWARE FOR EMBEDDED DEVICES
Universal Micro system is a general-purpose hardware that can be programmed and used to develop applications for different embedded devices
Many modern appliances like MP3 players, ‘intelligent’ refrigerators, and watches use embedded systems. However, a common obstacle for developers has been the need to develop different sets of hardware and software, for different devices. An ‘intelligent’ washing machine uses a hardware chip different from that used by an ‘intelligent’ wristwatch. In addition, the software running on the hardware chip is different. This often results in increased costs and time taken for development. (For more on embedded systems see PCQuest May2001,page38.)
The Universal Micro System (UMS) from Cradle Technologies is a solution for this problem. UMS is a general-purpose chip built around a simple instruction set. It can be used to develop applications for embedded devices because all the functionality required for a specific device can be modeled in the software.
UMS HARDWARE
Any software application expects four basic requirements from the underlying hardware: input unit, processing unit, memory unit, and output unit. Since the major functionality provided in UMS is through software, the processor and memory units must be very fast and the input-output units must be programmable and versatile.
UMS uses a large number of high speed, low power and small RISC-based processors (about 75) on a single chip. Each processor also called a PE (processing Element) coupled with two Digital Signal Processors called DSE (Digital Signal Engines) form an MSP (Multi Stream Processor), which processes voluminous chunks (stream) of data.
The UMS is structured into a number of Quads. A Quad, as shown in the diagram to the left, consists of four MSPs, program or instruction cache, data cache and a programmable DMA (Direct Memory Access) unit. There is also a high throughput (about 4 GB/sec) global bus interface, which interconnects all of them in a Quad. The use of DSEs ensures smooth digital processing, while the powerful PEs carry out the arithmetic and logical functions on the processed data. Finally, the result of the processing is transferred from the local data cache of a Quad to an external SDRAM (Synchronous Dynamic Random Access Memory) module via the DMA unit. The UMS chip does have an onboard DRAM controller to interface with external SDRAM modules. Feeding each Quad with independent chunks of data can make optimal use of the raw processing speed of the UMS chip. It is claimed that UMS has a raw speed of over 15 GFLOPS (Giga Floating Point Operations per second) while consuming just 1.5 watts of power.
The Input/Output unit of UMS is programmable. You can program it to support processing unit dependant data transfers, or do a DMA data transfer where data transfers can take place without the intervention of the processing unit. In fact, the programmable I/O is claimed to be so versatile that it can be used to model PCI, SCSI, FireWire, or DSL interfaces using software. In other words, the I/O hardware is extensively programmable through software.
SOFTWARE ON UMS
The software design has eliminated the need for customized hardware. It has been left to the developer to utilize the power of the numerous processors by using efficient software algorithms. Optimally, each Quad must be fed with independent data blocks (called data parallelism). This is the responsibility of the software developer. What Cradle has provided are some tools to speed up this development: a C compiler, an assembler and a cross assembler, linker, debuggers, and most important, a software simulator of the hardware chip. A custom C-API (Application Programming Interface), comprising of UMS specific library functions, is also provided. These include libraries for TCP/IP, OpenGL 3D, PCI, FireWire, MPEG and DV encoding and decoding.

[attachment=14538]
CHAPTER I
INTRODUCTION
1.1 Introduction
Embedded systems are finding increasing application not only in domestic
applications but also in areas of industrial automation, automobiles, power
electronics, defence and space equipments. 8051s are the modern building blocks for
many embedded systems.
In spite of revolutionary advances in the field of electronics, 8051s play a
major role in the design of embedded control systems during the past two decades.
They are available in 8-bit versions and are manufactured by a number of leading
companies like Intel, Motorola, Philips, Hitachi, Atmel, Microchip, Dallas, Siemens
etc., . They are available in the market with various configurations for different
applications.
The project is mainly based on the Robotic technology. Mainly Robotic
technology is used for more advanced applications. In this project, PIR sensor is used
internally to Excellent performance infrared sensor for use in alarm burglar systems,
visitor presence monitoring, light switches and robots. These compact, easy to use
sensors can be easily implemented in your design .
1.2 BLOCK DIAGRAM
CHAPTER II
INTRODUCTION TO EMBEDDED SYSTEM
2.1 Embedded system
An embedded system is a special-purpose computer system designed to
perform one or a few dedicated functions, sometimes with real-time computing
constraints. It is usually embedded as part of a complete device including hardware
and mechanical parts. In contrast, a general-purpose computer, such as a personal
computer, can do many different tasks depending on programming. Embedded
systems have become very important today as they control many of the common
devices we use.
Since the embedded system is dedicated to specific tasks, design engineers can
optimize it, reducing the size and cost of the product, or increasing the reliability and
performance. Some embedded systems are mass-produced, benefiting from
economies of scale.
Physically, embedded systems range from portable devices such as digital
watches and MP3 players, to large stationary installations like traffic lights, factory
controllers, or the systems controlling nuclear power plants. Complexity varies from
low, with a single microcontroller chip, to very high with multiple units, peripherals
and networks mounted inside a large chassis or enclosure.
In general, "embedded system" is not an exactly defined term, as many
systems have some element of programmability. For example, Handheld computers
share some elements with embedded systems — such as the operating systems and
microprocessors which power them — but are not truly embedded systems, because
they allow different applications to be loaded and peripherals to be connected.
An embedded system is some combination of computer hardware and software,
either fixed in capability or programmable, that is specifically designed for a
particular kind of application device. Industrial machines, automobiles, medical
equipment, cameras, household appliances, airplanes, vending machines, and toys (as well as the more obvious cellular phone and PDA) are among the myriad possible
hosts of an embedded system. Embedded systems that are programmable are provided
with a programming interface, and embedded systems programming is a specialized
occupation.

[attachment=15449]
INTRODUCTION TO EMBEDDED SYSTEMS
What is an Embedded system?
An embedded system is one that has computer hardware with software embedded in it as one of its components. Or
We can define an embedded system as “A microprocessor based system that does not look like a computer”. Or
we can say that it is “A combination of computer hardware and software, and perhaps additional mechanical or other parts, designed to perform a dedicated function. In some cases, embedded systems are part of a larger system or product, as is the case of an antilock braking system in a car ”.
An embedded system is a special-purpose computer system designed to perform certain dedicated functions. It is usually embedded as part of a complete device including hardware and mechanical parts. (Wikipedia)
Significance
Due to their compact size, low cost and simple design aspects made embedded systems very popular and encroached into human lives and have become indispensable. They are found everywhere from kitchen ware to space craft. To emphasize this idea here are some illustrations.
Embedded systems everywhere?
Embedded systems span all aspects of modern life and there are many examples of their use.
a) Biomedical Instrumentation – ECG Recorder, Blood cell recorder, patient monitor system
b) Communication systems – pagers, cellular phones, cable TV terminals, fax and transreceivers, video games and so on.
c) Peripheral controllers of a computer – Keyboard controller, DRAM controller, DMA controller, Printer controller, LAN controller, disk drive controller.
d) Industrial Instrumentation – Process controller, DC motor controller, robotic systems, CNC machine controller, close loop engine controller, industrial moisture recorder cum controller.
e) Scientific – digital storage system, CRT display controller, spectrum analyser.
Were the embedded systems existing earlier ?
Yes, We have been enjoying the grace of embedded system quite a long time. But they were not so popular because in those days most of the embedded systems were designed around a microprocessor unlike today’s systems which were built around a microcontroller.
As we know a microprocessor by itself do not possess any memory, ports etc. So everything must be connected externally by using peripherals like 8255, 8257, 8259 etc. So the embedded system designed using microprocessor was not only complicated in design but also large in size. At the same time the speed of microprocessor is also a limitation for high end applications.
Why a microcontroller ?
A microcontroller is a single silicon chip with memory and all Input/Output peripherals on it. Hence a microcontroller is also popularly known as a single chip computer. Normally, a single microcomputer has the following features :
Arithmetic and logic unit
Memory for storing program
EEPROM for nonvolatile data storage
RAM for storing variables and special function registers
Input/output ports
Timers and counters
Analog to digital converter
Circuits for reset, power up, serial programming, debugging
Instruction decoder and a timing and control unit
Serial communication port
So, its no wonder to say that the microcontroller is the most sought after device for designing an efficient embedded system.
What is inside an embedded system ?
Every embedded system consists of custom-built hardware built around a Central Processing Unit (CPU). This hardware also contains memory chips onto which the software is loaded. The software residing on the memory chip is also called the ‘firmware’.
The operating system runs above the hardware, and the application software runs above the operating system. The same architecture is applicable to any computer including a desktop computer. However, there are significant differences. It is not compulsory to have an operating system in every embedded system.
For small appliances such as remote control units, air-conditioners, toys etc., there is no need fir an operating system and we can write only the software specific to that application. For applications involving complex processing, it is advisable to have an operating system.
In such a case, you need to integrate the application software with the operating system and then transfer the entire software on to the memory chip. Once the software is transferred to the memory chip, the software will continue to run for a long time and you don’t need to reload new software .
The next slide shows the layered architecture of an embedded system.
Now let us see the details of the various building blocks of the hardware of an embedded system.
Central Processing Unit (CPU)
Memory (Read only memory and Random access memory)
Input Devices
Output Devices
Communication interfaces
Application specific circuitry
This slide shows the Hardware architecture of an embedded system
Features of an embedded system
Embedded systems do a very specific task, they cannot be programmed to do different things.
Embedded systems have very limited resources, particularly the memory. Generally, they do not have secondary storage devices such as the CDROM or the floppy disk.
Embedded systems have to work against some deadlines. A specific job has to be completed within a specific time. In some embedded systems, called real-time systems, the deadlines are stringent. Missing a dead line may cause a catastrophe – loss of life or damage to property.
Embedded systems are constrained for power, As many embedded systems operate through a battery, the power consumption has to be very low.
Embedded systems need to be highly reliable. Once in a while, pressing ALT-CTRL-DEL is OK on your desktop, but you cannot afford to reset your embedded system.
Some embedded systems have to operate in extreme environmental conditions such as very high temperatures and humidity.
Embedded systems that address the consumer market (for example electronic toys) are very cost-effective. Even a reduction of Rs.10 is lot of cost saving, because thousands or millions systems may be sold.
Unlike desktop computers in which the hardware platform is dominated by Intel and the operating system is dominated by Microsoft, there is a wide variety of processors and operating systems for the embedded systems. So, choosing the right platform is the most complex task .
Classification of Embedded Systems
Based on functionality and performance requirements, embedded systems are classified as :
Stand-alone Embedded Systems
Real-time Embedded Systems
Networked Information Appliances
Mobile Devices
Stand-alone Embedded Systems
As the name implies, stand-alone systems work in stand-alone mode. They take inputs, process them and produce the desired output. The input can be electrical signals from transducers or commands from a human being such as the pressing of a button. The output can be electrical signals to drive another system, an LED display or LCD display for displaying of information to the users. Embedded systems used in process control, automobiles, consumer electronic items etc. fall into this category.
Real-time Systems
Embedded systems in which some specific work has to be done in a specific time period are called real-time systems. For example, consider a system that has to open a valve within 30 milliseconds when the humidity crosses a particular threshold. If the valve is not opened within 30 milliseconds, a catastrophe may occur. Such systems with strict deadlines are called hard real-time systems.
In some embedded systems, deadlines are imposed, but not adhering to them once in a while may not lead to a catastrophe. For example, consider a DVD player. Suppose, you give a command to the DVD player from a remote control, and there is a delay of a few milliseconds in executing that command. But, this delay won’t lead to a serious implication. Such systems are called soft real-time systems .
Networked Information Appliances
Embedded systems that are provided with network interfaces and accessed by networks such as Local Area Network or the Internet are called networked information appliances. Such embedded systems are connected to a network, typically a network running TCP/IP (Transmission Control Protocol/Internet Protocol) protocol suite, such as the Internet or a company’s Intranet.
These systems have emerged in recent years. These systems run the protocol TCP/IP stack and get connected through PPP or Ethernet to an network and communicate with other nodes in the network.
Here are some examples of such systems
A networked process control system consists of a number of embedded systems connected as a local area network. Each embedded system can send real-time data to a central location from where the entire process control system can be monitored. The monitoring can be done using a web browser such as the Internet Explorer.
A web camera can be connected to the Internet. The web camera can send pictures in real-time to any computer connected to the Internet. In such a case, the web camera has to run the HTTP server software in addition to the TCP/IP protocol stack.
The door lock of your home can be a small embedded system with TCP/IP and HTTP server software running on it. When your children stand in front of the door lock after they return from school, the web camera in the door-lock will send an alert to your desktop over the Internet and then you can open the door-lock through a click of the mouse
This slide shows a weather monitoring system connected to the Internet. TCP/IP protocol suite and HTTP web server software will be running on this system. Any computer connected to the Internet can access this system to obtain real-time weather information.
The networked information appliances need to run the complete TCP/IP protocol stack including the application layer protocols. If the appliance has to provide information over the Internet, HTTP web server software also needs to run on the system.
Mobile Devices
Mobile devices such as mobile phones, Personal Digital Assistants (PDAs), smart phones etc. are a special category of embedded systems. Though the PDAs do many general purpose tasks, they need to be designed just like the ‘conventional’ embedded systems.
The limitations of the mobile devices – memory constraints, small size, lack of good user interfaces such as full fledged keyboard and display etc. are same as those found in the embedded systems discussed above. Hence, mobile devices are considered as embedded systems.
However, the PDAs are now capable of supporting general purpose application software such as word processors, games, etc.
Languages for Programming Embedded Systems
Assembly language was the pioneer for programming embedded systems till recently. Nowadays there are many more languages to program these systems. Some of the languages are C, C++, Ada, Forth, and Java together with its new enhancement J2ME.
The presence of tools to model the software in UML, SDL is sufficient to indicate the maturity of embedded software programming
The majority of software for embedded systems is still done in C language. Recent survey indicates that approximately 45% of the embedded software is still being done in C language.
C++ is also increasing its presence in embedded systems. As C++ is based on C language, thus providing programmer the object oriented methodologies to reap the benefits of such an approach.
C is very close to assembly programming and it allows very easy access to underlying hardware. A huge number of high quality compilers and debugging tools are available for the C language.
Though C++ is theoretically more efficient than C, but some of its compilers have bugs due to the huge size of the language. These compilers may cause a buggy execution.
C language can definitely claim to have more mature compilers C++. Now in order to avail the extra benefits of C++ and plus to avoid buggy execution, experts are doing efforts to identify a subset of C++ that can be used in embedded systems and this subset is called Embedded C++ .
Communication Interfaces
For embedded systems to interact with the external world, a number of communication interfaces are available. They are
Serial Communication Interfaces (SCI):
RS-232, RS-422, RS-485 etc
Synchronous Serial Communication Interface:
I2C, JTAG, SPI, SSC and ESSI
Universal Serial Bus (USB)
Networks:
Ethernet, Controller Area Network, LonWorks, etc
Timers:
PLL(s), Capture/Compare and Time Processing Units

Discrete IO:
General Purpose Input/Output (GPIO)
Analog to Digital/Digital to Analog (ADC/DAC)
Which is the best suited microcontroller for design of embedded system?
There is always a trade off between efficiency and power dissipation. To know this, let us review the various types of microcontrollers and their specifications and the vendors.
From the previous slide we can find that the ARM processor is a strong option for better performance. But when we consider the power consumption, in the case of ARM it is around 400mW and the ATmega1031, AVR microcontroller consumes low power around 16.5mW, but provides low performance.
But the Texas instruments MSP430 with wide range of operation modes consumes only 1.2mW with reasonably good performance. So it is always left to the designer to choose a suitable device according to the requirement.
Design of an embedded system – a Case study
To understand the design of a simple embedded system let us first consider the idea of a data acquisition system. The data acquisition system is shown in the next slide.
For example let me consider a simple case of temperature measurement embedded system.
First we must select a temperature sensor like thermistor or AD590 or LM35 or LM335 or LM75 etc.
After this the analog data is converted into digital data and at the same time proper signal conditioning is done.
This digital input is fed to the microcontroller through its ports.
By developing a suitable program (Embedded C or Assembly) the data is processed and controlled.
For this purpose keil or Ride or IAR ARM Embedded workbench C compilers can be used.
Once the program is debugged, and found error free it can be dumped into the microcontroller flash memory using ISP (Philips - Flash magic or any ISP).
Now, your microcontroller chip acts as an embedded chip.
For the sake of clarity I present the block diagram of a
simple embedded system.

to get more information about Embedded System Design full report ppt and other related article please refer all these pages
http://studentbank.in/report-embedded-sy...using-hdls
http://studentbank.in/report-embedded-sy...ull-report
http://studentbank.in/report-transparent...tem-design
http://studentbank.in/report-embedded-systems-ppt

to get information about the topic embedded systems full report,ppt and related topic refer the page link bellow page

http://studentbank.in/report-embedded-systems-ppt

http://studentbank.in/report-embedded-sy...ull-report

http://seminarsprojects.in/attachment.php

http://studentbank.in/report-embedded-sy...ars-report

http://studentbank.in/report-embedded-systems-ppt

http://studentbank.in/report-embedded-systems-projects

http://studentbank.in/report-embedded-sy...ull-report

http://studentbank.in/report-automation-...ed-systems

http://studentbank.in/report-linux-in-em...ars-report

http://studentbank.in/report-smart-camer...ed-systems

to get information about the topic embedded systems full report,ppt and related topic refer the page link bellow page

http://studentbank.in/report-embedded-systems-ppt

http://studentbank.in/report-embedded-sy...ull-report

http://seminarsprojects.in/attachment.php

http://studentbank.in/report-embedded-sy...ars-report

http://studentbank.in/report-embedded-systems-ppt

http://studentbank.in/report-embedded-systems-projects

http://studentbank.in/report-embedded-sy...ull-report

http://studentbank.in/report-automation-...ed-systems

http://studentbank.in/report-linux-in-em...ars-report

http://studentbank.in/report-smart-camer...ed-systems