?? 00000010.htm
字號:
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 />s no longer in production, depending on the availability of a replacement sy <br />stem. This problem is a significant concern on the Distributed example syste <br />m. <br />Design challenge: <br />· Cost-effectively update old designs to incorporate new components. <br />6. Business model <br />The business models under which embedded systems are developed can vary as w <br />idely as the applications themselves. Costs, cycle time, and the role of pro <br />duct families are all crucial business issues that affect design decisions. <br />6.1. Design vs. production costs <br />Design costs, also called Non-Recurring Engineering costs (NRE), are of majo <br />r importance when few of a particular embedded system are being built. Conve <br />rsely, production costs are important in high-volume production. Embedded sy <br />stems vary from single units to millions of units, and so span the range of <br />tradeoffs between design versus production costs. <br />At the low-volume end of the spectrum, CAD tools can help designers complete <br /> their work with a minimum of effort. However, at the high-volume end of the <br /> spectrum the designs may be simple enough and engineering cost such a small <br /> fraction of total system cost that extensive hand-optimization is performed <br /> in order to reduce production costs. <br />CAD tools may be able to outperform an average engineer at all times, and a <br />superior engineer on very large designs (because of the limits of human capa <br />city to deal with complexity and repetition). However, in small designs some <br /> embedded computer designers believe that a superior human engineer can outp <br />erform CAD tools. In the Small system example a programmer squeezed software <br /> into a few hundred bytes of memory by hand when the compiler produced overl <br />y large output that needed more memory than was available. It can readily be <br /> debated whether CAD tools or humans are "better" designers, but CAD tools f <br />ace skepticism in areas that require extraordinary optimization for size, pe <br />rformance, or cost. <br />Design challenge: <br />· Intelligently trade off design time versus production cost. <br />6.2. Cycle time <br />The cycle time between identification of a product opportunity and product d <br />eployment (also called Time to Market) can be quite long for embedded system <br />s. In many cases the electronics are not the driving force; instead, product <br /> schedules are driven by concerns such as tooling for mechanical components <br />and manufacturing process design. Superficially, this would seem to imply th <br />at design time for the electronics is not an overriding concern, but this is <br /> only partially true. <br />Because the computer system may have the most malleable design, it may absor <br />b the brunt of changes. For example, redesign of hardware was required on th <br />e Mission Critical example system when it was found that additional sensors <br />and actuators were needed to meet system performance goals. On the Small exa <br />mple system, delays in making masked ROM changes in order to revise software <br /> dominate concerns about modifications (and programmable memory is too expen <br />?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -