?? 00000010.htm
字號:
3.2. Small size, low weight <br />Many embedded computers are physically located within some larger artifact. <br />Therefore, their form factor may be dictated by aesthetics, form factors exi <br />sting in pre-electronic versions, or having to fit into interstices among me <br />chanical components. In transportation and portable systems, weight may be c <br />ritical for fuel economy or human endurance. Among the examples, the Mission <br /> Critical system has much more stringent size and weight requirements than t <br />he others because of its use in a flight vehicle, although all examples have <br /> restrictions of this type. <br />Design challenges: <br />· Non-rectangular, non-planar geometries. <br />· Packaging and integration of digital, analog, and power circuits to reduc <br />e size. <br />3.3. Safe and reliable <br />Some systems have obvious risks associated with failure. In mission-critical <br /> applications such as aircraft flight control, severe personal injury or equ <br />ipment damage could result from a failure of the embedded computer. Traditio <br />nally, such systems have employed multiply-redundant computers or distribute <br />d consensus protocols in order to ensure continued operation after an equipm <br />ent failure (e.g., [10], [11]) <br />However, many embedded systems that could cause personal or property damage <br />cannot tolerate the added cost of redundancy in hardware or processing capac <br />ity needed for traditional fault tolerance techniques. This vulnerability is <br /> often resolved at the system level as discussed later. <br />Design challenge: <br />· Low-cost reliability with minimal redundancy. <br />3.4. Harsh environment <br />Many embedded systems do not operate in a controlled environment. Excessive <br />heat is often a problem, especially in applications involving combustion (e. <br />g., many transportation applications). Additional problems can be caused for <br /> embedded computing by a need for protection from vibration, shock, lightnin <br />g, power supply fluctuations, water, corrosion, fire, and general physical a <br />buse. For example, in the Mission Critical example application the computer <br />must function for a guaranteed, but brief, period of time even under non-sur <br />vivable fire conditions. <br />Design challenges: <br />· Accurate thermal modelling. <br />· De-rating components differently for each design, depending on operating <br />environment. <br />3.5. Cost sensitivity <br />Even though embedded computers have stringent requirements, cost is almost a <br />lways an issue (even increasingly for military systems). Although designers <br />of systems large and small may talk about the importance of cost with equal <br />urgency, their sensitivity to cost changes can vary dramatically. A reason f <br />or this may be that the effect of computer costs on profitability is more a <br />function of the proportion of cost changes compared to the total system cost <br />, rather than compared to the digital electronics cost alone. For example, i <br />n the Signal Processing system cost sensitivity can be estimated at approxim <br />ately $1000 (i.e., a designer can make decisions at the $1000 level without <br />undue management scrutiny). However, with in the Small system decisions incr <br />easing costs by even a few cents attract management attention due to the hug <br />e multiplier of production quantity combined with the higher percentage of t <br />otal system cost it represents. <br />Design challenge: <br />· Variable "design margin" to permit tradeoff between product robustness an <br />d aggressive cost optimization. <br />4. System-level requirements <br />In order to be competitive in the marketplace, embedded systems require that <br /> the designers take into account the entire system when making design decisi <br />ons. <br />4.1. End-product utility <br />The utility of the end product is the goal when designing an embedded system <br />, not the capability of the embedded computer itself. Embedded products are <br />typically sold on the basis of capabilities, features, and system cost rathe <br />r than which CPU is used in them or cost/performance of that CPU. <br />One way of looking at an embedded system is that the mechanisms and their as <br />sociated I/O are largely defined by the application. Then, software is used <br />to coordinate the mechanisms and define their functionality, often at the le <br />vel of control system equations or finite state machines. Finally, computer <br />hardware is made available as infrastructure to execute the software and int <br />erface it to the external world. While this may not be an exciting way for a <br /> hardware engineer to look at things, it does emphasize that the total funct <br />ionality delivered by the system is what is paramount. <br />Design challenge: <br />· Software- and I/O-driven hardware synthesis (as opposed to hardware-drive <br />n software compilation/synthesis). <br />4.2. System safety & reliability <br />An earlier section discussed the safety and reliability of the computing har <br />dware itself. But, it is the safety and reliability of the total embedded sy <br />stem that really matters. The Distributed system example is mission critical <br />, but does not employ computer redundancy. Instead, mechanical safety backup <br />s are activated when the computer system loses control in order to safely sh <br />ut down system operation. <br />A bigger and more difficult issue at the system level is software safety and <br /> reliability. While software doesn't normally "break" in the sense of hardwa <br />re, it may be so complex that a set of unexpected circumstances can cause so <br />ftware failures leading to unsafe situations. This is a difficult problem th <br />at will take many years to address, and may not be properly appreciated by n <br />on-computer engineers and managers involved in system design decisions ([12] <br /> discusses the role of computers in system safety). <br />Design challenges: <br />· Reliable software. <br />· Cheap, available systems using unreliable components. <br />· Electronic vs. non-electronic design tradeoffs. <br />4.3. Controlling physical systems <br />The usual reason for embedding a computer is to interact with the environmen <br />t, often by monitoring and controlling external machinery. In order to do th <br />is, analog inputs and outputs must be transformed to and from digital signal <br /> levels. Additionally, significant current loads may need to be switched in <br />order to operate motors, light fixtures, and other actuators. All these requ <br />irements can lead to a large computer circuit board dominated by non-digital <br /> components. <br />In some systems "smart" sensors and actuators (that contain their own analog <br /> interfaces, power switches, and small CPUS) may be used to off-load interfa <br />ce hardware from the central embedded computer. This brings the additional a <br />dvantage of reducing the amount of system wiring and number of connector con <br />tacts by employing an embedded network rather than a bundle of analog wires. <br /> However, this change brings with it an additional computer design problem o <br />f partitioning the computations among distributed computers in the face of a <br />n inexpensive network with modest bandwidth capabilities. <br />Design challenge: <br />· Distributed system tradeoffs among analog, power, mechanical, network, an <br />d digital hardware plus software. <br />4.4. Power management <br />A less pervasive system-level issue, but one that is still common, is a need <br /> for power management to either minimize heat production or conserve battery <br /> power. While the push to laptop computing has produced "low-power" variants <br /> of popular CPUs, significantly lower power is needed in order to run from i <br />nexpensive batteries for 30 days in some applications, and up to 5 years in <br />others. <br />Design challenge: <br />· Ultra-low power design for long-term battery operation. <br />5. Life-cycle support <br />Figure 2 shows one view of a product life-cycle (a simplified version of the <br /> view taken by [13]). <br />Figure 2. An embedded system lifecycle. <br />
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -