LIFL 2002-n 07 Juillet 2002 Publication LIFL 2002-n 07 UML Framework for Intensive Signal Processing Embedded Applications Cédric Dumoulin, Jean-Luc Dekeyser Laboratoire d'informatique Fondamentale de Lille, Université de Lille I, France 8 Jul. 2002 1
2
UML Framework for Intensive Signal Processing Embedded Applications Cédric Dumoulin, Jean-Luc Dekeyser Laboratoire d'informatique Fondamentale de Lille, Université de Lille I, France 8 Jul. 2002 Abstract We present a methodology to visually model intensive signal processing applications for embedded systems. This methodology is based on the Array-OL language. The idea is to represent an application as a graph of dependencies between tasks and arrays. It differs from the classical reactive programming or message passing paradigm. A task may iterate the same code on different patterns tilling its depending arrays. In this case, visual specifications of dependencies between the pattern elements are enough to define an application. The visual notation we propose uses the UML standard. This allows usage of existing UML tools to model an application. More, the application's model can be exported and saved in a standardized XMI format. The resulting application's model can then be imported by others tools performing automatic exploitation, like validation, transformation or code generation. This work is supported by the European ITEA project Sophocles (no 99038). 1 Introduction Future embedded systems, like the ones used by Telecom or Multimedia, will require more and more computation power in order to be able to do intensive signal processing and compute the ever growing data-flows. In this context, embedded systems are build by assembling high performance IP (Intellectual Properties SIMD, DSP) or multiprocessor boards like COTS (Components On The Shelf). Development of such systems relies on environments for specification; validation; simulation; compilation and execution support. These environments must answer industrial requirements minimize "time to market"; satisfy applicative characteristics; guarantee reusability; provide a formal description framework; implement automatic techniques for compilation, deployment and scheduling. These are the goals of the ITEA project Sophocles and this work is part of this project. Within this project, we propose one single standard visual environment allowing modeling of intensive signal processing application dedicated to embedded systems, modeling of the architecture and deployment of the applications onto architectures. In this paper we only describe the application modeling part. Our project is based on the Array-OL language [1]. This language is based on single assignment and explicit dependency expressions on time or space. We extend Array-OL capabilities by providing Object Oriented concept like inheritance and enabling realization of library of components. These extensions allow modeling of reusable components. We restrict our scope to intensive signal processing applications. This restriction and the use of the Array-OL formalism allow us to propose a methodology for specifying such applications and exploiting resulting models. The methodology is made up of strict rules 3
describing how to model intensive signal processing embedded applications using the UML modeling language. These rules include Eliminating explicit programming by offering visual modeling of signal processing applications. Reducing development time o By allowing complete or partial reuse of existing applications, independently of targeted architecture. o By providing libraries of ready to use components. Respecting standards and being compliant with tools that conform to standards. Being able to express completely the potential parallelism of an application data or tasks parallelism. Generating application code for targeted embedded systems. The interest in the use of a high-level visual formalism for the specification and simulation of signal processing applications for embedded systems is of twofold It provides an early complete functional specification. Using visual modeling tools, we propose a non-ambiguous notation associated with a formal semantic model that applies on several levels of the applications visual model for the algorithm specification, and in the future, the architecture of an embedded system and the deployment of the algorithm on this architecture. It allows the validation, performance evaluation and verification of the system design. We support the formal verification of the functionalities of applications by automatic generation of tests, with the help of Esterel [8]. The performance evaluation includes the description of the algorithm and, in the future, its mapping on a modeled architecture. The goal is the rapid development of real-world signal processing applications for embedded systems. In the remainder of this paper, we will describe the Array-OL language and develop reasons leading us to choose UML as a modelling language. Then we will describe our visual environment and finally we will conclude. 2 Array-OL Language Array-OL (Array Oriented Language [1]) was developed by Thomson Marconi Sonar (now Thales Underwater System) in order to fulfill the needs for specification, standardization and efficiency of the multidimensional signal processing. Array-OL relies on a graphical formalism in which the signal processing appears as a graph of tasks. Each task is performed on multidimensional arrays. The execution targets are network of workstations, mainly to tune applications, and heterogeneous SOC for embedded systems. Array-OL proposes a two level approach. The first level is a global level ( figure 1) and defines task scheduling in the form of dependencies between tasks and arrays. A second level, which is local ( figure 2), details the elementary actions realized by tasks on array elements. 4
figure 1 Array-OL global model a graph of tasks and data objects Global Model This looks like the well-known process network model. The application is represented as a graph where each node represents a task and the edges define dependencies between tasks. Each edge carries an array. Nevertheless, in the process network model, the graph edges carry a continuous token flow of all the tasks running in parallel. In the Array-OL model, an edge carries a unique array (which may be of infinite size) and each task is triggered only once. A graph node (task) execution produces its output arrays from its input arrays. The task specification and the details of the array element usage are hidden at this specification level. The array defines a data structure for signal processing Signal processing applications are organized around a regular and potentially infinite stream of data. Array-OL captures this stream in arrays with one possible infinite dimension. Some spatial dimensions of arrays used in signal processing correspond to sensors. Such sensors may be organized in a circle. Consequently, Array-OL array dimensions wrap around to form a toroid. Local Model it details the task specification. It defines the access to the data in the arrays and the computations to be done on those data. The whole task execution is divided into small identical computational units called Elementary Transformations (ET). An ET operates on subsets of the arrays called patterns. Output patterns (patterns in the output arrays) are produced by applying the ET on the patterns of the input arrays. So, a task always consists of an iterator constructor; whose iterations are independent. Fitting and Paving o Patterns are multidimensional arrays. Equidistant elements in a pattern are also equidistant in the array. A pattern may be defined by an origin in the array and a set of vectors (fitting vectors; one vector being associated to each dimension of the pattern). o Two equidistant output patterns are produced by two equidistant input patterns. The array paving with patterns is given by a first pattern in each array and a set of paving vectors. ET Library or Hierarchical Definition o For each paving iteration, the input patterns are extracted from the input arrays and an ET is applied on these patterns to produce the output. These patterns are then stored in the output arrays. o A library of predefined ETs is available on different computer architectures to process generic data parallel tasks. o A hierarchical extension of Array-OL allows the programmer to define his/her own ET in Array-OL. Input/output patterns of the first level are considered as arrays on the sub-level of the hierarchy. A new Array-OL global level defines tasks that manipulate these arrays. This hierarchical construction may be applied as many times as necessary. 5
figure 2 Array-OL local model For example, signal processing dedicated to detection systems refers to multidimensional arrays. As in digital sound processing, a first dimension allows sampling the signal in chronological order. A second dimension generally represents the different sensors; the temporal sampling is applied on each of them. During the signal processing, other dimensions may appear. For example during the FFT implementation a new dimension represents the frequency. The temporal reference is modified and matches the sampling of the different FFT execution ages. Despite its ability to express signal processing applications, Array-OL lacks a formal visual modeling tool and associated compilers. This is a gap that we wish to fill. 3 UML as Modeling Language We choose to use UML [2] as a modeling language for the following reasons UML is a recognized standard and becoming very popular especially in industry. UML offers extension mechanisms ("stereotype", "tagged value", "profile") allowing us to implements our own language elements without modifying UML. UML does not depend on any particular methodology. We can define and validate our own methodology. UML is a visual as well as a textual language. Different efficient tools (Rational Rose, Objecteering, ) allow visual modeling with UML. UML is modeled by a "meta model", itself specified by the MOF [9] (UML subset). This allows us to specify our own meta model. In a first step it will be an extension of the UML one. The conformity of models exchanged between tools is (in some way) ensured by the XMI / XML standard [10]. UML has been originally developed to model the artifacts of intensive software systems. This comprises application modeling, architecture modeling and mapping. Therefore, it is possible to specify an intensive signal processing application with UML. However, there is no methodology that allows automatic exploitation of models for signal processing applications, which is the gap that we wish to fill. Other projects in the area of real-time systems or embedded applications have also chosen UML as a modeling language. For instance, the "Specification and Description Language" (SDL) [3] proposes a new version with some steps towards UML. Also, the UML community works on extensions dedicated to real-time applications (UML-RT, RT-UML [4] [5]). Another project, "Embedded UML" [6] does a synthesis of existing models by retaining attractive points. All these projects deal with modeling applications that communicate by exchanging signals. The first two do not allow architecture modeling, while the last one separates application modeling, architecture modeling and the mapping of the application onto the architecture. Our approach differs from previous projects as we want to model embedded applications with the help of dependency expressions rather than by exchanging signals or message passing. 6
UML is known as a standard for visual modeling until now it is mainly used as a tool that can help modeling applications. Its use as a tool for complete code generation is not well known, but several current projects chose this approach. Automatic exploitation of models to generate complete code is possible only if the model description comes with strict modeling rules. In our case, automatic exploitation of a model is possible as we restrict ourselves to specification of intensive signal processing applications and we follow strict modeling rules that we will define. These rules are part of the methodology that we propose for intensive signal processing embedded applications. 4 UML - Array-OL The Proposal Our goal is the specification of signal processing embedded applications at a high level of abstraction. After analyses of different modeling techniques used by our industrial partners, we have deduced that an intensive signal processing system should respect following constraints Single assignment these are mainly multidimensional arrays produced once by a processing task and then consumed by another task. Single assignment facilitates visual specification of an application. Unification of space and time dimensions array dimensions are generally associated to concepts inherent to the application (hydrophones, captors, power ). One of them can be associated with time, allowing storage of the different values of these concepts during the life of the application. This dimension could be infinite for an embedded application. Expression of time and space dependencies it is the only path linking objects manipulated by program. It provides dependencies between input and output object elements (arrays) of each elementary task. Only objects needed to produce other objects are identified (at the level of arrays or array elements). It covers both space and time dimensions. It allows direct instances of compilation techniques. It ensures concurrency by expression of partial order based on object dependencies. In UML- Array-OL we identify two types of dependencies o Array dependency corresponding to global model o Iterative dependency corresponding to local level We have demonstrated in our previous work [3] that these constraints allow the expression of complex signal processing applications, as well as automatic exploitation of resulting specifications by simulators or compilers. In the next section we show how we can model signal processing applications using these constraints. We start by describing our proposed framework, then we show how it is translated to UML. Finally, we suggest an improvement making easy visual modeling of application. 4.1 Framework The main concept of our proposal is the "signal processing component" (sp-component), named by analogy with components from electronic printed circuits. An application is modeled by assembling "sp-components" connected, with "connections", by the way of their "ports". Sp-components represent Array-OL global model's tasks and connections among ports materialize dependencies. We have also added some Object Oriented concepts in order to enable reuse of sp-components. 7
Sp-components The sp-component is the main modeling element. It is composed of an interface and it embeds a behavior. The interface contains ports that are used as potential endpoints for connections. The interface is the only possibility for a component to interact with the outside word. The behavior represents the actions or tasks that component ensures to realize. Its implementation is encapsulated inside the component and is completely hidden from outside world. This allows changing its implementation independently of any other components, as long as the new implementation respects the behavior and the interface. The behavior is described in what we call the component's structure. It is a graph of (sub-) components connected by their ports. This structure allows a hierarchical description of components ( figure 3). An application is itself a component made of sub-components, themselves described with other components. As an alternative, the behavior can be described by the name of a function from an existing library of code, or written in some language. In these cases the component corresponds to an Elementary Task of Array-OL. component structure description sub-component description figure 3 A compound component structure. Ports The ports represent proxy for data available to components. They are used as endpoint of connections. They are directed and can be "in" if they require some inputs, or "out" if they provide some outputs. The interconnections of components by the way of their ports form a directed graph representing a dependency graph. The exact content carried by a port is intentionally not defined. The model of an application will define its own ports by specifying the carried data structure. This allows different definitions for data exchange with ports. As example, in the Array-OL model, ports are defined to carry arrays. Connections The connections are used to "connect" components. In reality, connections are done between ports of components. The connections can be "direct", or "controlled". In a direct connection, both endpoints represent the same data. To ensure consistency, only ports with compatible type can be directly connected. In a controlled connection, endpoints have different types and are connected by the way of a "tiler". This tiler describes how data are carried or transformed 8
between the endpoints. All tilers and sub-components found in one component structure are synchronized in order to ensure consistency of data provided to sub-components. As example, we will describe a component performing parallel signal processing (similar to the "local model" of Array-OL). We use to call such component an "Array-OL component". The idea is to create a component representing the parallel processing and a nested subcomponent representing the task applied in parallel over data (check the sub-component in figure 3). Component's ports are connected to nested task by controlled connections. These later represent an "iterative dependency" describing, in associated tiler, how array from one end is divided and iterated to patterns corresponding to the other end. Tilers cover the paving and fitting concept of Array-OL. All Tilers of the component are synchronized to ensure the synchronization of arrays consumed and produced by the nested task. This later is executed once for each resulting set of patterns. The model says nothing about how the nested tag is executed this can be done sequentially or in parallel. This choice is left to the compiler and depends of the targeted architecture. OO Concepts Sp-components can be defined in one place, and used in another place. Thus we have a class instance relationship similar to the one found in Object Oriented Language (OOL). Definition of a sp-component, or class, is made of component's interface and component's behavior. Spcomponent instances are found in component structure describing behavior. This separation between definition and instance allows having libraries of reusable components. Another contribution from OOL is the ability to define a component by inheriting from another one, like it is possible to define a new class by inheriting from another one. This allows reuse of existing sp-components. The same OO concepts can be applied to ports, allowing library of reusable ports and extension of the existing ones. A component with no behavior can be considered as an "interface" in the meaning of OO terminology. Interfaces are useful to define family of interchangeable components. Our proposed framework allows to model any signal processing applications which can be modeled with Array-OL. Furthermore, its strict definition allows its automatic exploitation by other tools like visualization, validation, simulation, code generation, 4.2 UML notation The translation of our framework to UML uses the stereotype and tagged value extension mechanism. Sp-components and ports are classes with appropriate stereotype, while attributes like port direction are specified with tagged values. The modeling can be done with any UML tools, but it is preferable to chose one able to export and import model in the standard XML/XMI way. This allows our automatic tools to exploit the model. Port The port concept is mapped to a class stereotyped <<port>>. A concrete port usually refines its description by adding attributes. In UML -Array-OL, all ports inherit from a well-known class called AolPort which defines basic array attributes element type, number of dimensions and size of each dimension. Component The Component concept is mapped to a class stereotyped <<component>>. The component interface is described by a set of attributes stereotyped <<port>>. Such attributes are typed by a class denoting a port and are associated to a tagged value specifying the direction. In addition to the attribute declarations, the class should also declares corresponding associations in order to be able to represent them later in other diagrams. Component interface can be 9
visually represented in a class diagram showing attributes and corresponding associations ( figure 4). <<port>> <<port>> +in1 +in2 <<spcomponent>> CompoundComponent <<port>> in1 <<port>> in2 <<port>> out Array1x16 +out <<port>> Array1x16 figure 4 A component interface in UML Connections There is no special element for direct connections. The stereotype <<port>> specifies that a port can be associated to another port. The controlled connections are materialized by classes stereotyped <<tiler>>. This stereotype specifies that a tiler must have some associations to the ports it controls. There is no behaviour associated to the stereotype it is the concrete class responsibility to specify it. For the UML -Array-OL like signal processing applications, we specify a root class AolTiler defining all UML - Array-OL tilers' attributes like paving, fitting, and origin. Component Structure The component behaviour, or component structure, is visually described in a collaboration diagram sub-components and ports are represented by objects with the type of component or port they stand for. All ports used in the structure definition must be present. The links between ports and components they belong to must be drawn. The dependencies or interconnection of components are materialized by connecting corresponding ports with a direct link or with two links separated by a tiler instance. It is possible to add fictitious message exchanges in order to visually depict the direction of dependencies. The object (sp-components, ports or tilers) attribute values that need to be defined in the structure are also specified in this diagram. Filter1 in1 AolComponent Array1x16 out Array1x16 Filter2 in2 figure 5 A sp-component structure in UML 10
origin={0,0} paving={0,1} fitting={1,0} origin={0,0} paving={0,1} fitting={} Tiler ElementaryTask Array1x16 Scalar Tiler Array1x16 Tiler Array1x16 origin={0,0} paving={1,0} fitting={0,1} figure 6 A Array-OL component in UML OO Concepts Libraries of components are easily organized by using the package concept of OOL and UML. In the same way, sp-components, ports and tilers inheritance naturally fit to the UML extend association. All other UML concepts can also be used, allowing extension of the framework, or use of other existing frameworks. Using the proposed notation to model a signal processing application, it is possible to generate a standard XML / XMI file corresponding to the application model, and then let automatic tools exploit it. 4.3 Improvement Structure Diagram The description of component behavior, or structure, with a collaboration diagram is often tedious for each component we need to add instances of its ports, and represent links between ports and components. To improve readiness and simplify application modeling, we propose another view on component structure the "structure diagram". A "structure diagram" represents exactly the same things found in a component's "collaboration diagram", but expressed in a way more adapted to dependency specifications. In the proposed structure diagram, the component currently defined is represented as a surrounding box containing sub-components which are represented as nested box. The interface's ports are drawn on the border of the component with an indication of the direction. The connections between components are materialized by links between corresponding ports, possibly with a tiler drawn on the connection. 11
Filter1 in1 Filter2 AolComponent out in2 figure 7 structure diagram of a compound component. Ideally, implementation of this structure diagram should also be able to render attribute values; to navigate between components' structure diagrams by clicking on the appropriate component; to declare ad hoc attributes when we drag and drop a port or a component, The structure diagram, and more especially its internal representation, is also useful to simplify tools doing automatic exploitation. They now manipulate concepts more linked to dependency expressions than the collaboration diagram. Te proposed structure diagram is largely inspired from its counterpart in UML-RT. Its usage should be familiar to users of this formalism. The difference is, once again, that links represent dependency expressions instead of signal exchanges. 4.4 Meta Model The concepts used in our framework are modeled in a meta model extending the UML ones by adding our new elements. The meta model can be seen as a way to define elements used in UML Array-OL. By following the MOF standard to specify our meta model, we inherit from several related technologies The meta model can be exchanged thanks to MOF to XMI translations rules. Also, it can be used to translate resulting models (i.e. signal processing applications) to or from other specification languages. Some works exist to automatically translate models from a meta model to models of another meta model. The resulting models also inherit from the XMI translation rules, allowing a standard way to persist them in XML / XMI. A standardized way is defined to generate Java (JMI) or Corba (OMG) interfaces and implementations allowing importing or exporting a model in XML / XMI. Thus generated interfaces and implementations can be used to implement automatic tools. Providing a meta model allow us to have a standard way to specify and persist signal processing application models and to build compatible tools with the same standard internal representation. 5 Conclusion and Future Works We have presented a methodology to visually model intensive signal processing applications using the UML standard visual notation and the Array-OL formalism based on dependency expressions. This methodology allows development, simulation and code generation of reusable "pieces of software" aimed to intensive signal processing embedded applications. Reuse is one of the key to reduce development time and to achieve the "time to market" constraint. 12
The resulting models of signal processing applications can be exploited automatically by tools like visualization, simulation, transformation, code generation, This is possible because we restrict our domain to intensive signal processing applications and because we strictly specify the rules on how to model such applications. We have validated this work with an experimental platform called Gaspard. With this platform we are able to specify a signal processing application and to generate corresponding code for a simulation environment. The existing code generators can easily be extended to generate code for specific SOC or embedded systems. In the future, heterogeneous embedded systems will be taken into account by adjunction of the architecture and deployment specification in what we call a "Y" model (separation of application, architecture and deployment description). Tools like code generators will be able to process this new information. The architecture and deployment specifications will follow the same formalism used for the application description, providing a consistent set of high level specification tools for embedded system design, simulation and code generation. We also consider integration of new elements to our "visual language". As example, we will develop a new kind of dependency allowing modeling of irregular applications with non systematic processing. 6 References [1] Alain Demeure and Yannick Del Gallo. An Array Approach for Signal Processing Design. Sophia-Antipolis conference on Micro-Electronics (SAME), France, Oct. 1998. [2] OMG / UML. Unified Modeling Language (UML. OMG document formal/01-09-67. http//www.omg.org. [3] Andreas Prinz, Reinhard Gotzhein, Uwe Glasser, and Robert Eschbach. SDL Formal Semantics, Z.100.F, ITU-T, International Telecommunication Union. Draft. http//www.informatik.hu-berlin.de/~prinz/semantics/z100f_geneva.doc. [4] UML Profile for Schedulability, Performance and Time. OMG document ptc/02-03-02. Mar. 2002. [5] B. Selic and J. Rumbaugh. Using UML for Modeling Complex Real-Time Systems. Rational Rose, 1998. [6] Grant Martin and Luciano Lavagno and Jean-Louis Guerin. Embedded UML a merger of real-time UML and co-design. Mar. 2001 [7] Pierre Boulet and Jean-Luc Dekeyser and Jean-Luc Levaire and Philippe Marquet and Julien Soula and Alain Demeure. Visual Data-parallel Programming for Signal Processing Applications. 9th Euromicro Workshop on Parallel and Distributed Processing, PDP 2001, Feb 2001, Mantova, Italy. [8] Gérard Berry. The Esterel Language Primer. Informal Reference Manual. Sophia- Antipolis, France, 1999. [9] OMG / MOF. Meta-Object Facility (MOF). OMG document formal/2001-11-02, Nov. 2001. http//www.omg.org [10] OMG / XMI. XML Model Interchange (XMI). OMG document formal/2002-01-01, Jan. 2002. http//www.omg.org 13