Embedded Systems Design Europe - May 2008 - (Page 19)

software terface layer that is hardware dependent – changing when the hardware in the system changes. By applying the architecture template consistently across several program platforms, the goal would be to decrease the development time from one project to another while improving the maintainability of the software product. Let’s start off by viewing the overall system as an object that is partitioned into several smaller objects or layers. Some of these objects are written to be reusable while others, by design, are dependent on the hardware and have to change when the hardware changes. We can divide the system into four distinct layers as shown in Figure 1. The perceived system behavior, the outermost layer of the system, is where the users expect a certain behavior, typically deﬁned in a functional requirements document. For example, when someone pushes the call button for an elevator, they expect that within some reasonable amount of time the elevator door will open allowing the person to enter and choose a desired ﬂoor. For example, let’s assume that the project requires a vehicle velocity input. One customer might deﬁne the terminator for this input as the vehicle speed, derived from the engine control module and transmitted via a two-wire serial communications link. Another customer, requiring the same input, may specify that the terminator is a wheel speed sensor, which requires processing in order to derive the vehicle speed. In either case, the customer dictates the type of terminator that is available to the system even though the core requirement is vehicle speed. The “core-software” layer, by design, is a hardware-independent layer. This layer determines the appropriate action given a set of inputs and drives the outputs to a desired state. This part of the software executes the algorithms necessary to provide the desired function that the customer has required. The inputs and outputs (in other words, external terminators to the system) to this layer are pre- or post-processed by the interface layer and the data is typically passed to the layer through random access memory (RAM) variables. Between the hardware and core software layers is the “interface” layer. This layer links the hardware with the software and, by design, is tied to the hardware making it reusable for any other system that uses identical hardware. Figure 1 is an illustration of the layers that compose the entire system. When applying this model to an antilock braking system (ABS) on an automotive vehicle (see Figure 2), the outer layer is the level that the user interacts with the system. The main input at this level is the brake pedal that translates the force applied at the pedal to braking torque at the wheels. The core software determines if a wheel lock-up is imminent and regulates the individual wheel brake pressures to maintain the maximum trac19 The next layer is the “hardware” layer. This layer deﬁnes the various sensors and actuators used to provide information to the core software object. This layer deﬁnes the terminators for the system, which in many cases is dictated by the customer. These terminators are often constraints applied to the design. www.embedded.com/europe | embedded systems design europe | MAY 2008 http://www.embedded.com/europe

Table of Contents Feed for the Digital Edition of Embedded Systems Design Europe - May 2008

Embedded Systems Design Europe - May 2008 Contents Microsoft Provides Embedded Roadmap Enea Buys Developers Irish Start-Up Raises Funds for Telecom FPGAs Kontron Promotes COM Express Nano Mentor Nucleus Platform Provides UI for Atmel Small Form Factor Boards Head for the SUMIT Proffibus Advances IO-Link Integration Embedded Developers Cautious on Multicore Auto Cooperation Improves Test Altera Launches DO-254 Partner Network Building an ‘Instant-Up’ Real-Time Operating Systems An Architecture for Reusable Embedded Systems Software Free up Bandwidth in PCI Express Evaluating Software in Medical Devices Circuit Sensitivity in Analog Circuits Choosing Flash Memory New Products Advertising Contacts

Embedded Systems Design Europe - May 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.