78.htm

pcb设计资料初学者难得的入门资料包含工厂制作过程

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>
First a need or opportunity to deploy new technology is identified. Then a p <br>

roduct concept is developed. This is followed by concurrent product and manu <br>
facturing process design, production, and deployment. But in many embedded s <br>
ystems, the designer must see past deployment and take into account support, <br>
 maintenance, upgrades, and system retirement issues in order to actually cr <br>
eate a profitable design. Some of the issues affecting this life-cycle profi <br>
tability are discussed below. <br>
5.1. Component acquisition <br>
Because an embedded system may be more application-driven than a typical tec <br>
hnology-driven desktop computer design, there may be more leeway in componen <br>
t selection. Thus, component acquisition costs can be taken into account whe <br>
n optimizing system life-cycle cost. For example, the cost of a component ge <br>
nerally decreases with quantity, so design decisions for multiple designs sh <br>
ould be coordinated to share common components to the benefit of all. <br>
Design challenge: <br>
· Life-cycle, cross-design component cost models and optimization rather th <br>
an simple per-unit cost. <br>
5.2. System certification <br>
Embedded computers can affect the safety as well as the performance the syst <br>
em. Therefore, rigorous qualification procedures are necessary in some syste <br>
ms after any design change in order to assess and reduce the risk of malfunc <br>
tion or unanticipated system failure. This additional cost can negate any sa <br>
vings that might have otherwise been realized by a design improvement in the <br>

 embedded computer or its software. This point in particular hinders use of <br>
new technology by resynthesizing hardware components -- the redesigned compo <br>
nents cannot be used without incurring the cost of system recertification. <br>
One strategy to minimize the cost of system recertification is to delay all <br>
design changes until major system upgrades occur. As distributed embedded sy <br>
stems come into more widespread use, another likely strategy is to partition <br>
 the system in such a way as to minimize the number of subsystems that need <br>
to be recertified when changes occur. This is a partitioning problem affecte <br>
d by potential design changes, technology insertion strategies, and regulato <br>
ry requirements. <br>
Design challenge: <br>
· Partitioning/synthesis to minimize recertification costs. <br>
5.3. Logistics and repair <br>
Whenever an embedded computer design is created or changed, it affects the d <br>
ownstream maintenance of the product. A failure of the computer can cause th <br>
e entire system to be unusable until the computer is repaired. In many cases <br>
 embedded systems must be repairable in a few minutes to a few hours, which <br>
implies that spare components and maintenance personnel must be located clos <br>
e to the system. A fast repair time may also imply that extensive diagnosis <br>
and data collection capabilities must be built into the system, which may be <br>
 at odds with keeping production costs low. <br>
Because of the long system lifetimes of many embedded systems, proliferation <br>

 of design variations can cause significant logistics expenses. For example, <br>
 if a component design is changed it can force changes in spare component in <br>
ventory, maintenance test equipment, maintenance procedures, and maintenance <br>
 training. Furthermore, each design change should be tested for compatibilit <br>
y with various system configurations, and accommodated by the configuration <br>
management database. <br>
Design challenge: <br>
· Designs optimized to minimize spares inventory. <br>
· High-coverage diagnosis and self-test at system level, not just digital c <br>
omponent level. <br>
5.4. Upgrades <br>
Because of the long life of many embedded systems, upgrades to electronic co <br>
mponents and software may be used to update functionality and extend the lif <br>
e of the embedded system with respect to competing with replacement equipmen <br>
t. While it may often be the case that an electronics upgrade involves compl <br>
etely replacing circuit boards, it is important to realize that the rest of <br>
the system will remain unchanged. Therefore, any special behaviors, interfac <br>
es, and undocumented features must be taken into account when performing the <br>
 upgrade. Also, upgrades may be subject to recertification requirements. <br>
Of special concern is software in an upgraded system. Legacy software may no <br>
t be executable on upgraded replacement hardware, and may not be readily cro <br>
ss-compiled to the new target CPU. Even worse, timing behavior is likely to <br>

be different on newer hardware, but may be both undocumented and critical to <br>
 system operation. <br>
Design challenge: <br>
· Ensuring complete interface, timing, and functionality compatibility when <br>
 upgrading designs. <br>
5.5. Long-term component availability <br>
When embedded systems are more than a few years old, some electronic compone <br>
nts may no longer be available for production of new equipment or replacemen <br>
ts. This problem can be especially troublesome with obsolete processors and <br>
small-sized dynamic memory chips. <br>
When a product does reach a point at which spare components are no longer ec <br>
onomically available, the entire embedded computer must sometimes be redesig <br>
ned or upgraded. This redesign might need to take place even if the system i <br>