Platform-based Design
Various forms of platform-based
design have been used for many years. The basic advantages of PBD are as
follows:
-
It lays the foundation for
developing economically feasible design flows because it is a structured
methodology that theoretically limits the space of exploration, yet still
achieves superior results in the fixed time constraints of the design. A
platform is an abstraction layer in the design flow that facilitates a
number of possible refinements into a subsequent abstraction layer in the
design flow. The design process progresses through a series of platforms and
each platform layer defines bounds for what is achievable by mapping into
it, while offering faster design and lower risk.
-
It provides a formal mechanism to
identify the most critical hand-off points in the design chain: the hand-off
point between system companies and IC design companies and the one between
IC design companies and manufacturing companies represent the articulation
points of the overall design process. For instance, semiconductor companies
need to minimize risks when designing standardized chips. Hence, they need
to have a fairly complete characterization of the application spaces they
wish to target together with the associated constraints in terms of
affordable costs and performance levels. By the same token, system companies
need to have an accurate characterization of the capabilities of the chips
in terms of performance such as power consumption, size and timing, as well
as “Application Program Interfaces” (APIs) that allow the mapping of their
application into the chip at a fairly abstract level. APIs must then support
a number of tools to ease the possibly automatic generation of the
personalization of the programmable components of the chips.
-
It eliminates costly design
iterations because it enables derivative design, i.e. the technique of
building an application-specific product by assembling and configuring
platform components in a rapid and reliable fashion. For instance, a
hardware platform is a family of architectures satisfying a set of
constraints imposed to allow reuse of hardware and software components.
Then, an API platform can be developed to effectively extend the hardware
platform toward the application software, thus enabling quick, reliable,
derivative design.
-
The identification of precisely
defined layers (platforms), where the refinement and abstraction
processes take place. The layers then support designs built upon them, where
upper layers are isolated from lower level details but letting enough
information transpire about lower levels of abstraction. This is oriented to
allow design space exploration with a fairly accurate prediction of the
final implementation properties. The information should be incorporated in
appropriate parameters that annotate design choices at the present layer of
abstraction.
An Informal Description of PBD
A platform is a library of
components together with their composition rules. A design at each level of
abstraction is a platform instance, i.e., a legal composition of a set of
library elements. The library not only contains computational blocks that carry
out the appropriate computation but also communication components that are used
to interconnect the functional components. Each element of the library has a
characterization in terms of performance parameters together with the
functionality it can support. For every platform level, there is a set of
methods used to map the upper layers of abstraction into the platform and a set
of methods used to estimate performances of lower level abstractions.
The meet-in-the-middle process
is the combination of two efforts:
-
Bottom-up: build a platform by
defining its components and their performance abstraction (e.g., number of
literals for technology independent optimization, and area and propagation
delay for a cell in a standard cell library).
Establishing the number,
location, abstraction and components of intermediate platforms is the essence of
platform-based design. The trade-offs involved in the selection of the number
and characteristics of platforms relate to the size of the design space to be
explored and the accuracy of the estimation of the characteristics of the
solution adopted. Naturally, the larger the step across platforms, the more
difficult is predicting performance, optimizing at the higher levels of
abstraction, and providing a tight lower bound. In fact, the design space for
this approach may actually be smaller than the one obtained with smaller steps
because it becomes harder to explore meaningful design alternatives and the
restriction on search impedes complete design space exploration. Ultimately,
predictions/abstractions may be so inaccurate that design optimizations are
misguided and the lower bounds are incorrect.
The principles are summarized
in Figure 1 where the hour-glass represents the notion of meet-in-the-middle,
architectural exploration and platform mapping.
Figure 1
A Formal
Interpretation of PBD
As we have seen, an essential
component of PBD is the successive refinement process that takes from the higher
layers of abstractions to the final implementation. The refinement process is
interpreted as the concretization of a function in terms of the elements of an
architecture. The process of design consists of evaluating the performance of
different kinds of architectures by mapping the functionality onto its different
elements. The implementation is then chosen on the basis of some cost function.
We have cast the successive refinement design flow in a formal framework
described in terms of abstract algebra that was introduced in the hybrid
modeling chapter. The formal framework allows defining verification methods and
synthesis approaches that would otherwise be impossible.
PBD for Ad
hoc Wireless Sensor Networks (AWSN)
The wireless sensor network
domain presents several challenging problems, it is characterized by hard
real-time constraints, it has to be fault tolerant and design-error free, and it
has to react to a nondeterministic adversary environment. Ad hoc wireless sensor
networks are designed for environmental monitoring application. We emphasize a
PBD methodology that favors re-use at all levels of abstraction. The use of PBD
in this context is also useful to define layers of abstraction that can be used
to identify standards that enable the use of this fairly new technology.
Currently, AWSN designs are
rather ad-hoc and tailored to the specific application both in the choice of the
network protocols and in the implementation platform. Today, it is virtually
impossible to start developing applications without the previous selection of a
specific, integrated hardware/software platform. Coupling applications with
specific hardware solutions slows down the practical deployment of sensor
networks: potential users hesitate to invest in developing applications that are
intrinsically bound to specific hardware platforms available today.
A Standard
for the Development of Implementation Independent Applications
To unleash the power of AWSNs,
standards are needed that favor:
To address the first concern,
several efforts have been recently launched to standardize communication
protocols among sensor network nodes. Realizing that the present efforts are
lacking generality and, to a certain degree, rigor, we propose in this paper an
approach for the support of true interoperability between different applications
as well as between different implementation platforms. We advocate a top-down
approach similar to the one adopted very successfully by the Internet community
and propose a universal application interface, which allows programmers to
develop applications without having to know unnecessary details of the
underlying communication platform, such as air interface and network topology.
Hence, we define a standard set of services and interface primitives (called the
Sensor Network Services Platform or SNSP) to be made available to an application
programmer independently on their implementation on any present and future
sensor network platform. Furthermore, we separate the virtual platform defined
by the logical specification of the SNSP services from the physical platform
(called the Sensor Network Implementation Platform or SNIP) that implements it
and determines the quality and cost of the services.
As the definition of sockets in
the Internet has made the use of communication services independent of the
underlying protocol stack, communication medium and even operating system, the
application interface we propose identifies an abstraction that is offered to
any sensor network application and supported by any sensor network platform.
Yet, while similar in concept, the application interface needed for sensor
networks is fundamentally different from the one defined in the Internet space.
In the latter, a seamless set-up, use, and removal of reliable end-to- end
communication links between applications at remote locations are the primary
concern. On the other hand, sensor network applications require communication
services to support queries and commands among the three essential components of
the network (sensor, monitor/controller, and actuator), and need also other
services for resource management, time synchronization, locationing and dynamic
network management.
The Design
Flow
A specification can be loosely
defined as a description of a system. It may be informal and consist of just a
few graphical sketches or sentences in natural language, or be formally
described using a language with formal semantics. The design of a system
consists of a sequence of steps, in which new details are gradually introduced
until the physical implementation. Each step identifies a specification at a
different level of abstraction. At the most abstract levels, a specification
defines the functionality of the system as a whole, at more refined levels, it
usually consists of a network of distinct components interacting and cooperating
to realize a required collective behavior.
The behavior of a system is
defined by the sequences of actions that it takes as a response to input stimuli
from its environment. Actions are the elementary units of behavior that make the
system evolve from one state to another. Actions can be of several types:
computation (perform arithmetic operations), control (select the next action to
be taken), read/write (read or modify variables). Embedded systems
specifications, especially in networking and multimedia applications, are
heterogeneous and include a mix of different types of actions. Two actions whose
order of execution is not specified are said to be concurrent, as they may occur
in any order or at the same time. They are said to be in conflict, if either one
is executed as a result of a control decision. They are causally ordered, if one
is always executed before the other. Distributed system specifications usually
consist of sequential objects that run concurrently and communicate through
other objects called channels storing the messages they exchange.
A specification is usually
associated with a set of constraints that are expressions on quantities that are
not defined in the present specification yet, but will be defined after further
implementation steps. In other words, constraints define properties that must be
satisfied by valid implementations of a given specification. For example, bounds
on the communication delay are usually given at the beginning of the design
process, but quantities such as time and power are defined only after an
implementation architecture is selected (e.g. choosing the processor that runs
the software tasks defines the reaction time of an embedded system
implementation).
In a distributed system
specification, the network supporting the communication among components is one
of the major factors of complexity. The initial network specification is defined
by the behavior of the interacting components and is associated with cost and
performance requirements. As the design proceeds, the network specification is
successively refined: the structure is described in terms of the topology (nodes
and links), the behavior in terms of the protocols that rule the exchange of
messages among components. Protocol specifications include several types of
actions that are either in sequence (“send an acknowledgment after receiving the
packet”), or in conflict (“forward packet to upper layer if correct otherwise
discard it“), or concurrent (“write to multiple channels”). Constraints on
protocol implementations usually concern QoS parameters such as error rate,
throughput, maximum delay, and duration of a service. The types of actions in a
protocol specification and the type of constraints drive the choice of the
physical resources that define the physical implementation. Protocols can be
fully implemented in HW, in SW, or as a mix of the two. HW is the preferred
choice for protocols with tight power and real-time requirements. SW
implementations are chosen when mostly flexibility matters and timing and power
issues are not so critical. Therefore, protocols are usually implemented
partially as software tasks running on a processor and partially as Application
Specific Integrated Circuits (ASICs) and Field Programmable Gate Arrays (FPGAs).
Communication networks are
commonly designed decomposing the problem into a stack of layers following the
OSI reference model. Each protocol layer with the underlying channels defines a
platform that provides communication services to the upper layers and, at the
top of the stack, to the application-level components. There is an ongoing
debate about the use of the OSI protocol stack since its layering structure is
standard and application-independent, therefore, rather inefficient to use in
those applications where optimization is of paramount importance such as
wireless sensor networks.
Our approach is to leverage
the idea of layering the protocol stack in the design of wireless sensor network
as in the OSI model but not to fix a priori the layers themselves.
By allowing the freedom of choice in the layer structure, we aim to optimize
along criteria such as power consumption, reliability and response time since
the applications of wireless sensor networks depend critically on these
quantities. As a result, the protocol stack architecture includes only the
layers that are relevant for the target application and the protocol functions,
rather than being assigned a priori to specific layers, are introduced in the
position where the services they offer are required.
To implement an AWSN
networks, the functionality is mapped onto a Network Platform (NP) that consists
of a set of processing and storage elements (nodes) and physical media
(channels) carrying all the messages exchanged by nodes. Nodes and channels are
the architecture resources in the NP library and can be identified to a first
extent by some parameters like processing power and storage size for nodes, and
bandwidth, delay and error rate and for channels. Usually, according to PBD,
choosing a Network Platform requires selecting from its library an appropriate
set of resources and a network topology: for each parameter a broad range of
options is usually available. Therefore, the design space to be explored is very
wide. Moreover, choosing an NP is especially challenging for distributed
wireless networks, because of the inherent lossy nature of the physical channels
that connect the nodes. In these cases, when reliable communication is required,
like in our system target, it is necessary to introduce additional resources
(that is, reliable acknowledgement protocols) to overcome the effects of noise
and interference. However, introducing reliable and complex protocols requires
adding more processing power and more memory capabilities in the nodes. As a
result, the protocol constraints often dominate the implementation cost function
and the design effort. Therefore, in selecting an NP, we balance the cost of all
different components and trade between the use of complex protocols and the
adoption of more reliable physical or logical wired/wireless channels.
Automotive
Control
An automotive engine control
unit is a reactive real-time embedded system, since it is designed to control
the behavior of a physical system (namely, the engine) with tight timing
constraints. Reactive real-time embedded systems, referred to as embedded
controllers also, are the most challenging embedded systems to design.
In the standard approach to
embedded controller design, a serious problem is the present disregard for the
interaction of the control algorithms with their implementation. This neglect
leads to long re-design cycles when the timing and accuracy requirements of the
applications are not met. The proposed design methodology is based on the
principles of platform-based design. To illustrate the use of the methodology,
we consider the design of engine control units (ECUs) for motorcycles, which is
particularly suited for this approach due to the very tight cost constraints and
the complexity of the functionalities to be implemented. Motorcycle embedded
controllers are quite simpler than engine control units for cars. Considerably
complex devices such as electronic throttle valve control and cruise control,
are not adopted in motorcycles. However, motorcycle ECUs present all the tight
interactions with the plant that are present in car applications and that make
the design of ECUs very challenging. We focus on the upper three layers of PBD,
namely, the functional decomposition layer, the control strategies layer and the
implementation abstraction layer (which is the first layer where implementation
details are considered in the design flow). The importance of these platform
layers derives from the fact that most of the critical design choices are taken
in the early stages of the design flow and misconceptions in these stages
produce costly and time-consuming re-design cycles. These are crucial steps in
the process since the functional aspects of the design and the implementation
characteristics are both handled. The following steps are somewhat easier to
carry out since they take place in the implementation domain where abstractions
are easier to identify correctly. Hybrid system techniques are extensively used
to evaluate the behavior of the system at each layer. Figure
|
 |
Figure 1 The design flow
Figure 2
shows a detail view of the last step in the automotive design flow. The set of
possible algorithmic solutions are pruned to find the best match with the
implementation platform. This goal is achieved by adding non functional platform
effects, captured by implementation abstract models, to the control algorithms.
The control algorithms are allocated to the hardware and software architecture.
The latter requires the definition of a set of software tasks and/or processes,
the selection of the real-time operating system and the selection of the CPU. In
the automotive domain, a process is a software implementation of a control
algorithm that is statically scheduled inside a task. In case of a distributed
implementation, the control algorithms are allocated to several ECUs and the
communicating signals must be mapped to the network packets (called messages).
After the allocation, the scheduling of the tasks and messages must be carried
out.
|
 |
Figure
2 Detailed control algorithms
implementation design step
The effects of these choices
are taken into accounts by the abstract implementation models that allow the
verification of the specification and the evaluation of the cost (or
flexibility) function. After the allocation and scheduling, the control
algorithms mapped to software can be synthesized to generate the relative
software components. The verification of this step is typically performed with
the zero time assumption: the software execution takes always zero time. There
have been several attempts to model and simulate functional and non functional
aspects. The Metropolis project has been already mentioned as the most advance
design environment supporting separate specifications of the functionality, the
platform model and then the mapping of the former into the latter.
The potential
impact of platform based design on the automotive domain, the most mature of the
applications considered in the COLUMBUS project, is also discussed in the brief
report “Impact
of platform-based design methodology in Magneti Marelli Powertrain design flow”,
prepared by Walter Nesci of Magneti-Marelli, one of the industrial teams that
collaborated in the COLUMBUS project.
Electrical Motors
An appropriate subset of the
layers of abstraction used for the automotive application can also be used for
the design of electric drives. The essential gain in this domain is the
possibility of designing for non idealities of the computing platform at the
functional level thus allowing for early detection of errors and short
time-to-market while satisfying tight performance constraints.
The goal of our research activity is applying concepts of the
PBD methodology to electrical drives controllers design with particular
attention to speed and efficiency of the function-to-implementation design
process.
Electric motors are widely
adopted in all those applications where electrical power has to be converted
into mechanical power and vice versa. In recent years we witnessed a complex
evolution regarding the employment of digitally controlled electrical drives
within industrial and consumer applications. From a technological point of view,
almost all the classical solutions employing direct current motors have been
replaced by those making use of digitally controlled alternating current motors.
The introduction of various vector-controlled drives has allowed the dynamic
performance of a.c. drives
to match or sometimes even to surpass that of the d.c. drive. By using vector
control, in fact, it is possible to control separately the flux and torque
producing components of the supply current.
Digitally controlled drives
have spread very fast to the industrial world. Starting from the classical
application fields where the velocity control is needed (tooling machines,
robotics, rolling-mills, etc.), the employment of electrical drives is also
extending to applications where the velocity control is optional, the reason of
that being energy saving characteristics (pumps, fans, compressors, etc.) or
better performance requirements (such as hanging loads movement). Nowadays, on
the contrary, we witness a fast growth in the use of electrical drives in
consumer and domestic fields. Just think about cooling and conditioning
applications, both for domestic and commercial use. Several different
applications can be mentioned, such as washing machines, elevators, portable
tools. Furthermore, in domestic applications, the present and future needs for
new control strategies, smarter diagnosis features and the possibility for
remote interaction among different appliances (domotics), ask for the presence
of on-board intelligent (programmable) systems, such as microprocessor systems.
Their presence can also be effectively exploited for the control of the
electrical drive itself to satisfy important system requirements such as: high
energy efficiency and performance, cost effectiveness and comfort. Among the
emerging applications of digitally controlled electrical drives we can mention
the automotive area, where a lot of drives are employed on-board for widespread
tasks. The economical relevance of such phenomenon is very important, because
they represent wider markets than industrial ones.
By analysing the general aspect
of such different and spread applications, there are essentially three types of
motors: induction motors, permanent magnet synchronous motors (both brushless
a.c. and d.c.) and reluctance motors. These solutions allow meeting the
requirements for automation and integration of the drive system when controlled
by means of dedicated digital devices (microprocessors, digital signal
processors, etc.) and specific control algorithms, as a function of both the
adopted motor and the specific application.
The development of digital
control techniques for electrical drives and power converters provides the
possibility of carrying out flexible control systems that can be easily adapted
to different applications with as little modifications as possible or varying
only the software. At the moment, there are no ultimate solutions to achieve the
described potentiality. Then, even if there is room for innovative proposals, a
considerable design effort is necessary to characterise the most convenient
choices and to attain a valid and cost effective product within reasonably short
times.
In this sense, it would be of
great interest to leverage both hardware and software design methodologies and
tools for electrical drives that, starting from the specifications of the actual
application, would allow design and performance verification, both on a
simulation environment and on the actual system, with the lowest impact
regarding development and prototyping times. In fact, due to competition and
customer’s demand, the market for electrical drive systems forces suppliers of
control units to shorten development times while at the same time improving
system performance. This requires fast implementation of modern and
sophisticated control algorithms in the drive system. As short time-to-market is
essential, developing new control methods on the embedded control system would
be too inefficient and time-consuming.
The solution to this quandary
in our opinion is applying control design and simulation software with a
seamless transition to a real-time test environment. Moreover the two opposite
demands for high performance and cost reduction of drive systems ask for a
complete functional analysis of hardware/software partitioning and integration
also in the earlier steps of the design cycle.
In this sense
Platform-Based-Design represent an essential component for design organisation
and partitioning. The recursive nature of that methodology allows dealing with
the design task at different levels of refinement, both for the hardware and
software design process.
As far as the definition of the
hardware architecture is concerned, the essence of the problem is the choice of
the systems requirements for the development of a flexible platform for the
control of electrical drives, with particular attention to the hardware/software
integration and partitioning of the functions to be implemented. The obtained
results in terms of design tools and methodologies could then be adopted for
each specific case aiming at reducing the global design and development time,
thus allowing cost reduction and reliability improvements.
As far as the definition of the
software architecture, the reduction of the design cycle and the prototyping
times could be obtained by the definition of an electrical drive simulation
package, including a library of the optimised dynamical models of the overall
drive system. The simulation platform should also be designed in order to allow
control system design and including the target-system code generation feature.
The PBD methodology is applied
to the development of sensor-less high-performance control algorithm for
interior permanent magnet synchronous motors. Sensor-less control represents in
fact the future of electrical drives, involving complex control techniques that
require high computational burden and hardware/software interaction representing
a particularly important and challenging research topic.
|
