GB2441432A

GB2441432A - An Automated Model Based Procedure for Integrating a Functional with a Physical System Architecture to form an Electronic System.

Info

Publication number: GB2441432A
Application number: GB0716690A
Authority: GB
Inventors: Andre Windisch; Stefan Forster; Marco Fischer; Burkhard Balser
Original assignee: EADS Deutschland GmbH
Current assignee: Airbus Defence and Space GmbH
Priority date: 2006-08-30
Filing date: 2007-08-28
Publication date: 2008-03-05
Also published as: FR2905491B1; FR2905491A1; DE102006040698A1; GB0716690D0

Abstract

The invention relates to an automatic, model-based procedure for integrating a functional system architecture with a physical system architecture to form an electronic system, in particular an avionics system. The functional system architecture comprises individual application components and the physical system architecture comprises individual platform components. Assignment of application components to platform components is performed in such a way that a)the assignment is complete; b) the functional sequence of the functional system architecture is assured, and c) the nonfunctional requirements for the overall system are fulfilled.

Description

Automatic, model-based procedure for integrating a functional system

architecture with a physical system architecture to form an electronic system The invention relates to an automatic, model-based procedure for integrating a functional system architecture with a physical system architecture to form an electronic system, in particular an avionics system. Such systems are those having a plurality of processors and being connected to a plurality of networks (so-called "distributed embedded systems") In the development of integrated modular avionics systems (IMA), the software functionality is developed, independently of hardware, in the form of a function graph. This so-called functional architecture can be integrated, distributed to various hardware platforms (so-called physical architecture), with regard to hardware-specific and operating-system-specific boundary conditions. This distribution is defined

in system tables.

IMA systems are currently being introduced in many new flying systems (e.g. Airbus A380, Eurofighter); corresponding IMA system tables have to be compiled by hand. The high system complexity is manifested in extensive system tables which, if compiled manually, may have a high error rate. System malfunction caused by erroneous or inconsistent IMA system tables is difficult to locate as such, since it typically presents itself to the user as a functional error.

The object of the invention is to create an automatic, model-based procedure for integrating functional and physical system architecture.

With this object in view, the invention envisages a procedure according to Claim 1. With embodiments of the invention, an automatic, model-based procedure integrates a functional system architecture (also termed application in the following) with a physical system architecture (also termed platform in the following) to form an electronic system, in particular an avionics system, wherein the functional system architecture comprises individual application components and the physical system architecture comprises individual platform components. Assignment (also termed linking in the following) of application components to platform components is performed in such a way that I. the assignment is complete, as in the fifth step described below; II. the functional sequence of the functional system architecture is assured; and III. the non-functional requirements for the overall system are fulfilled.

In a first step, the specification of the functional system architecture and of the physical system architecture is provided, these specifications having the following characteristics: I. both platform components and application components form a hierarchy, in which sub-components represent a structural refinement of the associated parent components, II. further connections, functions and attributes can be added both to platform components and to application components through extension of the behaviour of these components, and III. the platform components have so-called logical platform sub-components as placeholders for application components to be added later.

In a second step, the set of logical platform sub-components of the physical system architecture is determined.

In a third step, the set of application components to be assigned to the physical system architecture is determined, the assignment of an application component to a platform component being admissible if I. an application component also exists as a logical platform sub-component of the platform component, or II. an application component is derived from a logical platform sub-component of the platform component through behaviour extension.

In an advantageous embodiment, if the assignment of an application component to a platform component is not admissible, it is possible to check whether the linking of a parent component of the application component is admissible.

In a fourth step, the set of clusters of application components is determined, a cluster comprising such application components that have to be assigned to the same platform component.

In a fifth step, a first system variant is generated through complete assignment of the clusters of application components to the platform components.

In a sixth step, checking is performed to determine whether the generated system variant fulfils predefined functional and non-functional requirements; if the check proves negative, the assignment of the clusters to the platform components is changed to generate new system variants, such changing being effected until an admissible system variant is obtained.

Finally, in a seventh step, the admissible system variant is transformed into a system table for the electronic system.

The present invention offers the following advantages when used in aircraft: -Increased efficiency in the integration of IMA systems, owing to automation and inherently assured consistency; -Quickening of incremental changes in the IMA system design, owing to automation of important system integration steps; -Reusability of components and configured system variants, owing to storage in a databank; long-term build-up of 4 4 know-how, and potentially greater efficiency in the development of new IMA systems; -Generation of system tables capable of being adapted to various platforms through simple substitution of the system table generator (e.g. ASAAC/ARINC), with the system configurator and the databank format remaining the same (ASAAC and ARINC are internationally standardized IMA platforms) For a better understanding of the invention, embodiments of it will now be described, by way of example, with reference to the accompanying drawings, in which: Fig. 1 shows the general diagram of an arrangement for executing the procedure according to the invention; Fig. 2 shows a diagram relating to component categories and component characteristics; Fig. 3 shows examples (Figs. 3a-3c) for the structural refinement of components; Fig. 4 shows a diagram relating to the extension of behaviour of components; Fig. 5 shows a diagram relating to the principle of the

description of layers;

Fig. 6 shows an application; Fig. 7 shows a platform; Fig. 8 shows a partial linking of an application to a platform; Fig. 9 shows the sequence of the procedure according to the invention; Fig. 10 shows a diagram relating to the sequence of the second step of the procedure according to the invention; Fig. 11 shows a diagram relating to the sequence of the third step of the procedure according to the invention; 4 5 Fig. 12 shows a diagram relating to the sequence of the fourth step of the procedure according to the invention; Fig. 13 shows a diagram relating to the sequence of the fifth step of the procedure according to the invention; and Fig. 14 shows a representation relating to the sequence of the seventh step of the procedure according to the invention.

Fig. 1 is a general representation of an arrangement for executing the procedure according to the invention.

The databank 1 logs, in the form of formal component descriptions, both hardware resources and software functions.

This comprises the formally described functional behaviour and non-functional characteristics of the components. The specification 2, consisting of functional (application) and physical (platform) system architecture, is compiled by the system designer. Existing components from the databank 1 may be used therein. In addition, existing tools may be used to describe and import new components (multi-formalism). The configurator 3 has the task of bringing together the two parts of the specification by determining an assignment of application components (software) to platform components (hardware), such that a) the assignment is complete, b) the functional sequence of the application is assured, and c) the non-functional requirements of the overall system are fulfilled. The system variant 4 thus generated by the configurator 3 exists in a format that is independent of the target system. Determined system variants can therefore be stored, wholly or partially, in the databank for subsequent reuse. The function of the system-table generator 5 is to transform the system variant into a format that is dependent on the target system. The system table 6 generated by the system table generator contains all information required for configuration of the target. system. The system table is read and processed by the target system itself. 4 6

Formal specification methodology (Figs. 2 to 8)

The procedure of the invention is based on a formal specification methodology. This methodology is described in the following, preceding a detailed explanation of the actual procedure according to the invention.

1. Component-based description

The component-based description (also specification) of processing and communication functionalities by means of so-called processing components and communication components, or component descriptions, within the scope of this invention includes: a) ports for data flow modelling b) methods for control flow modelling, and C) attributes for describing non-functional characteristics such as, for example, bandwidths of network systems, execution times, dimensions of hardware modules, etc. As shown in Fig. 2, a distinction is made between ports of the inputu / "output" I "inout" categories and methods of the "provided" / "required" categories. Components with methods of the "required" category require the input of one or more subroutines. Components with methods of the "provided" category provide functions in the form of one or more subroutines.

Attributes within the meaning of this invention have a name, a type, a value range (according to type), a default value (according to type) and an optional evaluation function.

2. Description of structural refinement

It is possible to use sub-components as a means of structurally refining components, as represented by way of example in Figs. 3a-c, with reference to the components DPM, MMM and GPM. The structural refinement is used for modelling the system hierarchy. 4 7

This method of structural refinement is based on a parent component being modelled by means of any number of sub-components, and the data flows (via ports) and control flows (via methods) between these sub-components being specified.

In the case of sub-components, a distinction is made between real sub-components and logical sub-components, the latter constituting placeholders (also termed "templates") for real sub-components to be added later. For this purpose, it is possible to specify for a logical sub-component the minimum and maximum numbers of real sub-components to be added (see Fig. 3, where these values are stated on the left, beneath the sub-component).

Furthermore, functional dependences between the attributes of the parent component and the attributes of the contained sub-components are defined in the form of evaluation functions.

This is a general principle from compiler construction, applied here to system hierarchy.

3. Description of behaviour extension

It is possible to extend the behaviour of components, as represented in Fig. 4 with the example of processing components. Behaviour extension within the meaning of this invention enables further ports, methods and attributes to be added to a component. Behaviour extension is thus equivalent to the specialization concept in object-oriented programming languages (e.g. Java), i.e. a super-component is extended, in respect of its interfaces, to one or more (actual) sub-types of this component. The latter is represented graphically by a unidirectional arrow from sub-type component to super-component.

Behaviour extension may be applied both to processing components and to communication components. The formal modelling methodology described here defines the "extends" relation as a specification primitive for the behaviour extension. In mathematically correct terms (see Fig. 4) : a sub-type of a component a (e.g. MEM) is either the component itself or each component A' (e.g. ObstacleProvision) that is connected to A by means of an uninterrupted sequence of "extends" relations.

4. Description of (architecture) layers

This relates to the possibility of describing an architecture by means of layers, which divide a set of components into the two classes: platform components ("platform building blocks") and application components ("application building blocks") (Fig. 5) . The class of platform components in this case includes all those components from which an actual processing platform can be composed (in the sense of a computer network consisting of hardware and software; the latter is understood to include, in particular, the operating system) . The class of application components, on the other hand, includes all components from which platform-compliant applications can be produced. Possible linkings of application components to platform components are a constituent part of the description of the platform components, and are represented by means of "logical" (or virtual) sub-components of platform components (represented graphically by a broken-line border) For greater clarity, Figs. 6 and 7 represent the description of, respectively, a possible application and a platform, which have been derived from the above layer description.

5. Description of the application linking

This relates to the description of various variants of the assignment (linking) of an application, consisting of application components, to a platform, consisting of platform components. Such linking is possible only if all application components either exist in the platform as logical sub-components of a component or have been derived from such a sub-component by means of behaviour extension.

A possible linking of an application to a platform is described and explained, by way of example, in the following.

A graphical representation pertaining thereto is shown in Fig. 8, it being necessary to point out that, for the sake of clarity, only a partial linking of the application to the platform has been represented in the figure. A possible complete linking, on the other hand, might be as follows: 1) Processes "TerrainProvision" and "ObstacleProvision" are linked to the platform component "MMM", since only this platform component is able to execute application processes with a memory API (MEI1). These, according to Fig. 4, are all those application processes that have been derived from the process "MMMProcess" by means of behaviour extension.

2) The process "GraphicProcessing" is linked to platform component "GPM", since only this platform component is able to execute application processes with graphic API.

As can be seen from Fig. 4, the process "Graphic Processing" has been derived from the process GPMProcess by means of behaviour extension.

3) The processes "ProximityWarning" and "VisionControl" may be linked to the platform components MMM, DPf4 or GPM, since application processes that have been derived from the process "DP4Process" (see Fig. 4) can be executed on all three platform components (the platform components "MMM", "DP" or "GPM" each contain logical sub-components of the type DPMProcess) . For the sake of uniform load distribution, however, there will be linking to the platform component "DPM" (principle of static "load balancing") 4) After the processing components of the application have been linked to the platform, the associated communication components are linked. The following description is based on the assumption that the two processes "ProximityWarning" and "VisionControl" have been linked to the platform component "DPM".

5) The communication component "LocalVirtualChannel" (LVC) between the processes "Proximitywarning" and "VisionControl" is linked to the platform component "DPM".

6) All further communication components of the application are "GlobalVirtualChannels" (GVC), which enable communication between application processes on various platform components. GVCs cannot be linked directly, since corresponding "logical" components are not a constituent part of the module specification (see Fig. 3 for the platform component DPM) . Linked instead are the two sub-components "VCStub" of a GVC (see Fig. 5) . As represented in Fig. 8, this linking is distributed to the two platform components MNM, DPM, which execute the two processing functions of the application that communicate via the GVC.

7) If the assignment of an application component to a platform component is not admissible, it is possible to check whether the linking of a parent component of the application component is admissible. An example of this is the process "TerrainProvision" which, as a structurally refined parent component (see, for example, Fig. 4), is linked to the platform component MMN, all sub-components of the parent component being implicitly linked in conjunction with the latter.

Note: Fig. 8 is a composite of Figs. 10 and 11, and serves only to illustrate the linking of the components of the functional architecture (application) over the components of the physical architecture (platform). For graphical details in respect of application and platform design, reference is made to Figs. 10 and 11.

Configuration algorithm (Figs. 9 to 14) Fig. 9 gives a general overview of the configuration procedure according to the invention, and of the dependences between the individual steps. The individual steps describe the mapping (linking) of the application component (functional architecture) onto a platform component (physical architecture), and are described in detail in the following sections.

Step 1 In a first step, the specification of the functional system architecture (application AK) and of the physical system architecture (platform P1<) is provided (see Fig. 9) . Their description is based on the specification methodology described above.

Step 2 The oblect of this step is to determine the set of logical components offered by the platform component. An exemplary embodiment is represented in Fig. 10.

Input: platform component (PK) Output: the set PLK (logical components of the platform), a mapping of the logical components onto a set of possible parent components fvK() a. The set P< and the mapping fvK() are initially empty, i.e. PLK = fl and fvK() = {} b. The set P contains the components not yet examined for logical components, and initially contains only the P1<, i.e. PK PK} c. Provided that the set (1) PK is not empty (PK {fl, select a component K from PK and remove it from P, (2) P is empty (PK {}), go to f.

d. For each sub-component (UK) (if present) of K, find out if it (1) is a real sub-component, add it to PK (PK = PK U UK), (2) is a logical sub-component, add it to the set PLK (PLK = PLK U UK), additionally add K to f(UK) (fvK(UK) = fvK(UK) u K) e. Gotoc.

f. If PLK is empty (PLK {}), nothing can be linked to this platform component (error), otherwise PLK contains the set of logical components of P1<.

Step 3 The object of this step is to determine the set of application sub-components ABK to be linked. An embodiment is represented in Fig. 11.

Input application component AK and PLK Output: the set ASK (the application sub-components to be linked) a. The set ASK is initially empty, i.e. Asx H b. The set AK contains the components not yet examined for linking capability, and initially contains only the AK, i.e. AK = {AK} c. Provided that the set (1) AK is not empty (AK!= {}), select a component A from AK and remove it from AK, (2) AK is empty (AK {}), go to e.

d. If the component A (1) is a sub-type of a component in PLK, add A to ASK (ASK = ABK A), otherwise (2) has real sub-components, insert all real sub-components of A in AK, otherwise (3) cannot be linked on the platform (error) e. The set ASK contains all components to be linked to the platform.

Step 4 The object of this step is to determine direct boundary conditions of linking (linking constraints, in particular resulting from necessary local control flows and data flows) -here, local means on the same processor and thus in the same memory (on-board), through cluster formation, i.e., from ASK determine the set of clusters ABC to be linked. An embodiment is represented in Fig. 12. A cluster is those application components that necessarily have to be linked to the same platform component.

Input: A< (the application sub-components to be linked) Output: A8c (set of clusters, of application sub-components, to be linked) a. The set ABC is initially empty, i.e. ABC H b. Provided that the set (1) ABK is not empty (AEK!= {}), select a component A from ABK and remove it from ABK, otherwise (2) ABK is empty (AEK H), go to f.

c. Insert A in the set Aiuster (Aciuster {A)) d. Insert in Aciuster all components that are connected to A via control flows (requires/provides) or data flows (in/out/inout), remove these components from ABK; Aiuster thus contains all components connected to A (transitive closure) e. Insert Aciuster in ABC and go to b.

f. The set ABC contains all related clusters of the application component, each cluster consisting of components that can be linked to the platform Step 5 The aim of this step is to determine an initial linking of the clusters to the platform. An embodiment is represented in Fig. 13 (for the graphical details of the two components, see Figs. 10 and 11) Input: f() (mapping of logical components to their parent components), ABC (set of clusters, of application sub-components, to be linked) Output: S (system variant, consisting of two sub-components AK and PK, the AK being completely linked to the PK) a. Generate S, with two real sub-components AK and PK b. Provided that the set ABC (1) is not empty (ABC {}), select a cluster C from ABC, and remove it from ABC, otherwise (2) is empty (Aac {}), go to f.

c. From C, select a component K, make the set M equal to fvK(K) d. Provided that the set M (1) is not empty (M!= {}), select a component VK from M, and remove it from M, otherwise (2) is empty (M {}); it is then not possible to link the cluster C to the PK (error), or if clusters have already been assigned to the platform sub-component and these clusters can potentially also be linked to other platform sub-components (through a different choice in [d. (1)] or {b. (1) 1, this choice can then be reversed by back-tracking and a renewed attempt made to link C e. If the VK (1) has sufficient non-linked logical sub-components to assign all components of the cluster C to these logical sub-components, link the components of C to the corresponding logical sub-components of VK, and go to b (2) does not have sufficient non-linked logical sub-components to assign all components of the cluster C to these logical sub-components, go to d.

f. S is a completely linked system variant Step 6 In this step, the fulfilment of the functional and non-functional characteristics of the system variant is checked.

Input: S (completely linked system variant) Output S (valid system variant, i.e. fulfils the functional and non-functional characteristics) a. Checking of cumulative non-functional characteristics, e.g. (1) Memory requirement: Each linked application sub-component (Al, A2, ...) can define attributes with memory requirements (stack, heap, etc.). The memory requirement for the platform is the sum of all corresponding memory requirements of the application sub-components that are linked to a logical platform component (see step 5e. (1)) (Stacksum = Stack(Al) + Stack(A2) + ...). The direct platform parent component or one of its parent components can define a maximum memory size (e.g.: MaxHeap, etc.), so that it is possible to check whether there is actually sufficient memory available for the application components on the platform. If there is not sufficient memory available, this non- functional characteristic is not fulfilled, and the system variant is thus invalid (error). Back-tracking may be performed, in a manner analogous to that of step 5d.(2), to obtain a new system variant.

(2) Loads: Each application sub-component AUK defines a local task graph according to [1, 2) with the tasks T(AUK) = T1..., T. The linking of the AUKs produces a global task graph, from which the period of the respective tasks can be deduced. Once an application has been linked to a logical platform component PFK (see step 5e.(1)), the execution times of the tasks on this PFK can be determined. The load of a task T is then the ratio between execution time and period (load(T) = time(T, PFK) I period(T)). The set of tasks linked on a PFK is given by the set of all tasks of the linked application components (T(PFK) = T(AUK1) + T(AUK2) +

.) -The total load of a PFK can thus be determined by addition of all partial loads (load(PFK) = load(Tl) + load(T2) + ...). If this load is greater than 1, the PFK is overloaded, and the system variant is invalid (error). Back-tracking may be performed, in a manner analogous to that of step 5d. (2), to obtain a new system variant...DTD: It is to be pointed out that cumulative characteristics can already be checked in step Se. as an additional condition (i.e. sufficient non-linked logical components AND respective cumulative characteristic fulfilled) . This may be advantageous, since they can be checked very rapidly.

b. Checking of temporal non-functional characteristics, e.g. analysis of WCETS (Worst Case Execution Times) and BCETs (Best Case Execution Times) according to the method described in [1, 2], the procedure being adapted to the modelling described in Appendix B: (1> The platform components respectively define a WCET and BCET attribute, which are respectively associated with an evaluation function.

(2) These evaluation functions have, as an input parameter, the task T. This task T corresponds to a task linked on the platform component.

(3) Various evaluation functions exist in the databank for the various scheduling procedures (e.g. RMS, TDMA, etc.).

Following the calculation of the BCETs and WCETs, checking is performed to determine whether deadlines (time between two events, e.g. from the activation of a task until its deactivation) are adhered to, and whether the period of a task is exceeded by the WCET (WCET must be shorter than the period). If there is infringement of one of these two characteristics, (1) either: the priority (in the case of RMS) or the timeslot (in the case of TDMA) of the task is raised, and step [b.] is executed again, (2) or: back-tracking may be performed, in a manner analogous to that of step 5d. (2), to obtain a new system variant, (3) or: the system variant is rejected as being invalid (error).

c. Checking of functional characteristics, e.g. : absence of deadlock and livelock, attainability of system states.

Based on the formal description of the component model (process algebra according to [3]), a static analysis of the system variant is performed to identify possible deadlock and livelock states. If deadlocks or livelocks exist, or if required system states cannot be achieved, the system variant is invalid (error). This analysis may already be (partially) performed before step 2.

d. The system variant is valid when a., b. and c. have been performed successfully.

Step I The object of this step is to transform the verified system variant into a system table. An embodiment is represented in Fig. 14.

Input: SVER (valid system variant) tf() (an instruction for transforming components and attributes of the system variant into elements

of the system table)

Output: ST (system table) a. ST = tf(S) References [1] Razvan Racu, Kai Richter, Roif Ernst. Calculating Task Output Event Models to ReduceDistributed System Cost.

In GI/ITG/G1'.ff' Workshop Methoden und Beschreibungssprachen zur Modellierung und Verifikation von Schaltungen und Systernen, pages 1-10.

Kaiserslautern, Germany, February 2004.

[2] R. Henia, A. Haminan, M. Jersak, R. Racu, K. Richter, R. Ernst. System Level Performance Analysis -the SymTA/S Approach. IEEE Proceedings Computers and Digital Techniques, 2005.

[3] S. Forster, M. Fischer, A. Windisch, B. Balser, D. Monjau. A New Specification Methodology for Embedded Systems based on the Pi-Calculus Process Algebra. In Proceedings of the 14th International IEEE Workshop on Rapid System Prototyping (RSP), San Diego, USA, 2003.

Claims

Claims 1. An automatic, model-based procedure for integrating a

functional system architecture with a physical system architecture to form an electronic system, wherein the functional system architecture comprises individual application components and the physical system architecture comprises individual platform components, assignment of application components to platform components being performed in such a way that I. the assignment is complete; II. the functional sequence of the functional system architecture is assured; and III. the non-functional requirements for the overall system are fulfilled; wherein the procedure includes the following procedural steps: in a first step, the specification of the functional system architecture and of the physical system architecture is provided, these specifications having the following characteristics: I. both platform components and application components form a hierarchy, in which sub-components represent a structural refinement of the associated parent components, II. further connections, functions and attributes can be added both to platform components and to application components through extension of the behaviour of these components, and III. the platform components have so-called logical platform sub-components as placeholders for application components to be added later; in a second step, the set of logical platform sub-components of the physical system architecture is determined; in a third step, the set of application components to be assigned to the physical system architecture is determined, the assignment of an application component to a platform component being admissible if I. an application component also exists as a logical platform sub-component of the platform component, or II. an application component is derived from a logical platform sub-component of the platform component through behaviour extension; in a fourth step, the set of clusters of application components is determined, a cluster comprising such application components as have to be assigned to the same platform component; in a fifth step, a first system variant is generated through complete assignment of the clusters of application components to the platform components; in a sixth step, checking is performed to determine whether the generated system variant fulfils predefined functional and non-functional requirements; if the check proves negative, the assignment of the clusters to the platform components is changed to generate new system variants, such changing being effected until an admissible system variant is obtained, and in a seventh step, the admissible system variant is transformed into a system table for the electronic system.

2. A procedure according to Claim 1, in which, in the third step, if the assignment of an application component to a platform component is not admissible, checking is performed to determine whether the linking of a parent component of the application component is admissible.

3. A procedure according to claim 1 or 2, in which the system is an avionics system.

4. A procedure substantially as described herein with reference to the attached drawings.