DE102006040698A1 - Automated, model-based method for integrating a functional system architecture with a physical system architecture to an electronic system - Google Patents

Abstract

The invention relates to an automatic, model-based method for integrating a functional system architecture with a physical system architecture into 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. An assignment of application components to platform components is made such that I. the assignment is complete II. The functional sequence of the functional system architecture is ensured III. the non-functional requirements for the entire system are met.

Description

The The invention relates to an automatic, model-based method to integrate a functional system architecture with a physical system architecture to an electronic system, in particular an avionics system. These are systems that have multiple processors and are connected to multiple networks (called "distributed embedded Systems ").

at the development of integrated modular avionics systems (IMA) becomes the software functionality hardware-independent developed in the form of a function graph. This so-called functional Architecture can be considered of hardware-specific and operating system-specific framework conditions on different hardware platforms (so-called physical Architecture), be integrated. This distribution will enshrined in system tables.

IMA systems are currently used in many new flying systems (e.g., Airbus A380, Eurofighter), appropriate IMA system tables must be created by hand. The high system complexity manifests itself in extensive system tables, which in manual Creation can have a high error rate. System failure caused through faulty or inconsistent IMA system tables is hard as such, as it is typically a functional error for the Represents users.

It The object of the invention is an automatic, model-based method for integration of functional and physical system architecture to accomplish.

These Task is solved by the method according to claim 1. A advantageous embodiment is the subject of a sub-claim.

• I. die Zuordnung vollständig ist gemäß Schritt 5
• II. der funktionale Ablauf der funktionalen Systemarchitektur gewährleistet ist
• III. die nicht-funktionalen Anforderungen an das Gesamtsystem erfüllt werden.

According to the invention, an automatic, model-based method for integrating a functional system architecture (hereinafter also referred to as application) with a physical system architecture (also referred to below as a platform) to an electronic system, in particular an avionics system, created, wherein the functional system architecture comprises individual application components and the physical system architecture comprises individual platform components. An assignment (also referred to below as binding) of application components to platform components is undertaken such that

• I. the assignment is complete according to step 5
• II. The functional flow of the functional system architecture is ensured
• III. the non-functional requirements for the entire system are met.

• I. Plattformkomponenten als auch Applikationskomponenten bilden eine Hierarchie, bei der Unterkomponenten eine strukturelle Verfeinerung der zugehörigen Vaterkomponenten darstellen,
• II. mittels Verhaltenserweiterung von Plattformkomponenten als auch von Applikationskomponenten können diesen weitere Anschlüsse, Funktionen und Attribute hinzugefügt werden,
• III. die Plattformkomponenten weisen so genannte logische Plattformunterkomponenten als Platzhalter für später einzufügende Applikationskomponenten auf.

In a first step, the specification of the functional system architecture and the physical system architecture is provided, which have the following properties:

• I. platform components as well as application components form a hierarchy in which subcomponents represent a structural refinement of the associated parent components,
• II. By means of behavioral expansion of platform components as well as of application components, further connections, functions and attributes can be added to these
• III. The platform components have so-called logical platform subcomponents as placeholders for later to be inserted application components.

In a second step is the set of logical platform subcomponents determined by the physical system architecture.

• I. eine Applikationskomponente auch als logische Plattformunterkomponente der Plattformkomponente existiert, oder
• II. eine Applikationskomponente von einer logischen Plattformunterkomponente der Plattformkomponente durch Verhaltenserweiterung abgeleitet ist,

In a third step, the amount of the application components to be assigned to the physical system architecture is determined, wherein the assignment of an application component to a platform component is permitted if

• I. an application component also exists as a logical platform subcomponent of the platform component, or
• II. An application component is derived from a logical platform subcomponent of the platform component by behavior extension,

If the assignment of an application component to a platform component is not allowed can in an advantageous embodiment being checked, whether the binding of a parent component of the application component permissible is.

In a fourth step is the set of clusters of application components determined, wherein a cluster comprises such application components, which must be assigned to the same platform component.

In a fifth Step is a first system variant by complete assignment the cluster of application components on the platform components generated.

In a sixth step, it is checked whether the generated system variant fulfills given functional and non-functional requirements; If the test is negative, new system variants are generated by changing the assignment of the clusters to the platform components. until there is an admissible system variant.

In a seventh step finally will be the allowed System variant in a system table for the electronic system transformed.

• – Effizienzerhöhung bei der Integration von IMA-Systemen durch Automatisierung und inhärente Konsistenzsicherung;
• – Beschleunigung inkrementeller Änderungen im IMA-Systemdesign durch Automatisierung wichtiger Systemintegrationsschritte;
• – Wiederverwendbarkeit von Komponenten und konfigurierten Systemvarianten durch Speicherung in Datenbank; langfristiger Know-How-Aufbau und potentielle Effizeinzsteigerung bei der Entwicklung neuer IMA-Systeme;
• – Systemtabellen-Gernerierung adaptierbar für verschiedene Plattformen durch einfachen Austausch des Systemtabellen-Generators (z.B. ASAAC/ARINC), wobei Systemkonfigurator und Datenbankformat gleich bleiben (ASAAC und ARINC sind international standardisierte IMA-Plattformen).

The following advantages are associated with the present invention when used in aircraft:

• - Increase of efficiency in the integration of IMA systems through automation and inherent consistency assurance;
• Acceleration of incremental changes in IMA system design by automating key system integration steps;
• - Reusability of components and configured system variants through storage in database; long-term know-how build-up and potential increase in efficiency in the development of new IMA systems;
• - System table generation adaptable to different platforms by simply swapping the system table generator (eg ASAAC / ARINC) keeping the system configurator and database format the same (ASAAC and ARINC are internationally standardized IMA platforms).

The The invention will be described below with reference to specific examples closer to Fig explained. Show it:

1 the overall representation of an arrangement for carrying out the inventive method;

2 a representation of component categories and component properties;

3 Examples of the structural refinement of components;

4 a representation of the behavioral extension of components;

5 a representation of the principle of the description of layers;

6 an application;

7 a platform;

8th a partial binding of an application to a platform;

9 the course of the method according to the invention;

10 a representation of the end of the second step of the method according to the invention

11 a representation of the end of the third step of the method according to the invention;

12 a representation of the end of the fourth step of the method according to the invention;

13 a representation of the end of the fifth step of the method according to the invention;

14 a representation of the end of the seventh step of the method according to the invention.

1 is an overall view of an arrangement for carrying out the method according to the invention.

Database 1 captures both hardware resources and software functions in the form of formal component descriptions. This includes the formally described functional behavior and non-functional properties of the components. The specification 2 consisting of functional (application) and physical (platform) system architecture is created by the system designer. In doing so, existing components can be retrieved from the database 1 be used. In addition, new components can be described and imported using existing tools (multi-formalism). The configurator 3 has the task of merging the two parts of the specification by determining an assignment of application components (software) to platform components (hardware) so that a) the assignment is complete, b) the functional sequence of the application is guaranteed and c) not functional requirements are met by the overall system. The thus of the configurator 3 generated system variant 4 is in a format independent of the target system. As a result, determined system variants can be completely or partially stored in the database for later reuse. The task of the system table generator 5 consists of transforming the system variant into a format dependent on the target system. The system table generated by the system table generator 6 contains all the information needed to configure the target system. The system table is read and processed by the target system itself.

Formal specification methodology ( 2 to 8th )

The inventive method is founded on a formal specification methodology. This will be below described before the inventive method itself in detail explained becomes.

1. Component-based description

• a) Ports zur Datenflussmodellierung
• b) Methoden zur Kontrollflussmodellierung und
• c) Attribute zur Beschreibung nichtfunktionaler Eigenschaften, wie z.B. Bandbreiten von Netzwerksystemen, Ausführungszeiten, Abmessungen von Hardwaremodulen, etc.

The component-based description (also specification) of processing and commu nikationsfunktionalitäten means of so-called processing components and communication component respectively. Component descriptions within the meaning of this invention include:

• a) Ports for data flow modeling
• b) methods for control flow modeling and
• c) Attributes describing non-functional properties, such as bandwidths of network systems, execution times, dimensions of hardware modules, etc.

As in 2 A distinction is made between ports of the categories "input" / "output" / "inout" and methods of the categories "provided" / "required." Components with methods of the category "required" require the input of one or more subroutines The "provided" category provides functions in the form of one or more subroutines.

attributes For the purposes 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

There is the possibility of structural refinement of components by means of subcomponents, as in 3a C illustrated by way of example with reference to the components DPM, MMM, GPM. The structural refinement is used to model the system hierarchy.

This method of structural refinement is based on modeling a parent component using any number of subcomponents and specifying data flows (via ports) and control flows (via methods) between these subcomponents. Subcomponents are distinguished between true subcomponents and logical subcomponents, the latter representing placeholders (also called "templates") for real subcomponents to be inserted later. For this purpose, it is possible to specify for a logical subcomponent the minimum and maximum number of real subcomponents to be inserted (see 3 where these values are given to the left below the subcomponent).

Of others become functional dependencies between the attributes of the parent component and the attributes of the parent contained subcomponents in the form of evaluation functions Are defined. It is a general principle of the Compiler build, applied here to the system hierarchy.

3. Description of behavior extension

There is the possibility of behavioral extension of components, as in 4 on an example of processing components. The behavioral extension in the sense of this invention makes it possible to add further ports, methods and attributes to a component. Behavioral extension is therefore equivalent to the specialization concept in object-oriented programming languages (eg Java), ie a super-component is extended regarding its interfaces to one or more (more concrete) subtypes of this component. The latter is represented graphically by a unidirectional arrow from subtype component to super component.

Behavior extension can be applied to both processing and communication components. The formal modeling methodology described here defines the "extends" relation as the specification primitive for the behavioral extension, mathematically correct (see 4 ): A subtype of a component A (eg MEM) is either the component itself or each component A '(eg ObstacleProvision), which is connected to A by means of an uninterrupted sequence of "extends" relations.

4. Description of (architectural) layers

This concerns the possibility of describing an architecture by means of layers, which subdivide a set of components into the two classes "platform building blocks" and "application building blocks" ( 5 ). The class platform components contains all those components from which a concrete processing platform (in the sense of a computer network consisting of hardware and software, the latter in particular the operating system is to be taken) can be put together. In contrast, the class Application Components contains all components from which platform-compliant applications can be created. Possible bindings of application components to platform components are part of the description of the platform components and are represented by means of "logical" (or virtual) subcomponents of platform components (graphical representation by means of a dashed edge).

For the purpose of better understanding are in the 6 and 7 in each case the description of a possible application and a platform shown, which were derived from the above layer representation.

5. Description of the application binding

This concerns the description of different variants of the assignment (Binding) of an application consisting of application components on a platform consisting of platform components. Such Binding is only possible if all application components either as a logical subcomponent a component in the platform exist or from such Subcomponent derived by means of behavioral extension.

• 1) Prozesse „TerrainProvision" und „ObstacleProvision" werden auf die Plattformkomponente „MMM" gebunden, da nur diese Plattformkomponente Applikationsprozesse mit einem Speicher-API (MEM) ausführen kann. Dies sind, gemäß 4, all jene Applikationsprozesse, die von Prozess „MMMProcess" mittels Verhaltenserweiterung abgeleitet wurden.
• 2) Der Prozess „GraphicProcessing" wird auf Plattformkomponente „GPM" gebunden, da nur diese Plattformkomponente Applikationsprozesse mit Graphik-API ausführen kann. Wie 4 entnommen werden kann, wurde der Prozess "Graphic Processing" mittels Verhaltenserweiterung vom Prozess GPMProcess abgeleitet.
• 3) Die Prozesse „ProximityWarning" und „VisionControl" können auf die Plattformkomponenten MMM, DPM oder GPM gebunden werden, da Applikationsprozesse welche von Prozess „DPMProcess" abgeleitet wurden (siehe 4) auf allen 3 Plattformkomponenten ausgeführt werden können (die Plattformkomponenten „MMM", „DPM" oder „GPM" beinhalten jeweils logische Unterkomponenten vom Typ DPMProcess). Im Interesse einer gleichmäßigen Lastverteilung wird jedoch eine Bindung auf Plattformkomponente „DPM" erfolgen (Prinzip des statischen „Load Balancing").
• 4) Nach erfolgter Bindung der Verarbeitungskomponenten der Applikation auf die Plattform erfolgt die Bindung der zughörigen Kommunikationskomponenten. Nachfolgende Beschreibung beruht auf der Annahme, dass die beiden Prozesse „ProximityWarning" und „VisionControl" auf die Plattformkomponente „DPM" gebunden wurden.
• 5) Die Kommunikationskomponente „LocalVirtualChannel" (LVC) zwischen den Prozessen „ProximityWarning" und „VisionControl" wird wird auf die Plattformkomponente „DPM" gebunden.
• 6) Alle weiteren Kommunikationskomponenten der Applikation sind „GlobalVirtualChannels" (GVC), welche eine Kommunikation zwischen Applikationsprozessen auf verschiedenen Plattformkomponenten ermöglichen. GVCs können nicht direkt gebunden werden, da entsprechende „logische" Komponenten nicht Bestandteil der Modulspezifikation sind (siehe 3 für die Plattformkomponente DPM). Gebunden werden statt dessen die beiden Unterkomponenten „VCStub" eines GVC (sieh 5). Wie in 8 dargestellt, erfolgt diese Bindung verteilt auf die beiden Plattformkomponenten MMM, DPM, welche die beiden über den GVC kommunizierenden Verarbeitungsfunktionen der Applikation ausführen.
• 7) Falls die Zuordnung einer Applikationskomponente auf eine Plattformkomponente nicht zulässig ist, kann geprüft werden, ob die Bindung einer Vaterkomponente der Applikationskomponente zulässig ist. Beispiel hierfür ist der Pro zess "TerrainProvision", der als strukturell verfeinerte Vaterkomponente (siehe z.B. 4) auf die Plattformkomponente MMM gebunden wird, wobei alle Unterkomponenten der Vaterkomponente implizit mit gebunden werden.

The following example illustrates a possible binding of an application to a platform and explains it. A graphical representation shows this 8th It should be noted that in the interests of clarity, only a partial binding of the application to the platform was presented. A possible complete binding might look like this:

• 1) Processes "TerrainProvision" and "ObstacleProvision" are bound to the platform component "MMM", since only this platform component can execute application processes with a storage API (MEM) 4 , all those application processes derived from the "MMMProcess" process by means of behavior extension.
• 2) The "GraphicProcessing" process is bound to platform component "GPM", since only this platform component can execute application processes with graphics API. As 4 can be taken, the process "Graphic Processing" was derived by means of behavior extension of the process GPMProcess.
• 3) The processes "ProximityWarning" and "VisionControl" can be linked to the platform components MMM, DPM or GPM, as application processes derived from process "DPMProcess" (see 4 ) can be executed on all three platform components (the platform components "MMM", "DPM" or "GPM" each contain logical subcomponents of the type DPMProcess) However, in the interests of uniform load distribution, binding will take place on platform component "DPM" (principle of static) "Load balancing").
• 4) After the processing components of the application have been linked to the platform, binding of the associated communication components takes place. The following description is based on the assumption that the two processes "ProximityWarning" and "VisionControl" were bound to the platform component "DPM".
• 5) The communication component "LocalVirtualChannel" (LVC) between the processes "ProximityWarning" and "VisionControl" is bound to the platform component "DPM".
• 6) All other communication components of the application are "GlobalVirtualChannels" (GVC), which enable communication between application processes on different platform components.GVCs can not be bound directly, because corresponding "logical" components are not part of the module specification (see 3 for the platform component DPM). Instead, the two subcomponents "VCStub" of a GVC are bound (see 5 ). As in 8th As shown, this binding is distributed over the two platform components MMM, DPM, which execute the two processing functions of the application communicating via the GVC.
• 7) If the assignment of an application component to a platform component is not permitted, it can be checked whether the binding of a parent component of the application component is permitted. An example of this is the process "TerrainProvision", which is a structurally refined father component (see eg 4 ) is bound to the platform component MMM, with all subcomponents of the parent component being implicitly bound.

Note: 8th is a composition of the 10 and 11 and serves merely to illustrate the binding of the components of the functional architecture (application) via the components of the physical architecture (platform). For graphical details in terms of application and platform design is on the 10 and 11 directed.

Configuration algorithm ( 9 to 14 )

A general overview of the configuration method according to the invention and the dependencies between the individual steps is given in FIG 9 given. The individual steps describe the mapping (binding) of the application component (functional architecture) to 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 the physical system architecture (platform PK) are provided (see 9 ). Their description is based on the specification methodology outlined above.

step 2

• a. die Menge P_LK und die Abbildung f_VK() sind anfangs leer, d.h. P_LK = {} und f_VK() = {}
• b. die Menge P_K enthält die noch nicht auf logische Komponenten untersuchten Komponenten und enthält anfangs nur die PK, d.h. P_K = {PK}
• c. solange die Menge (1) P_K nicht leer ist (P_K ≠⁣ {}) wähle eine Komponente K aus P_K und entferne sie aus P_K, (2) P_K leer ist (P_K ≡ {}) gehe zu f.
• d. für jede (wenn vorhanden) Unterkomponente (UK) von K untersuche ob sie (1) eine echte Unterkomponente ist, dann füge sie zu P_K hinzu (P_K = P_K ∪ UK), (2) eine logische Unterkomponente ist, dann füge sie zur Menge P_LK hinzu (P_LK = P_LK ∪ UK) hinzu, weiterhin füge K zu f_VK(UK) hinzu (f_VK(UK) = f_VK(UK) ∪ K)
• e. gehe zu c.
• f. falls P_LK leer ist (P_LK ={}), dann kann auf diese Plattformkomponente nichts gebunden werden (Fehler), ansonsten enthält P_LK die Menge der logischen Komponenten von PK

The objective of this step is to determine the set of logical components offered by the platform component. An exemplary embodiment is in 10 shown.
Input: Platform Component (PK)
Output: the set P _LK (logical components of the platform),
a mapping of the logical components to a set of possible father components f _VK ()

• a. the set P _LK and the mapping f _VK () are initially empty, ie P _LK = {} and f _VK () = {}
• b. the set P _K contains the components not yet examined for logical components and initially contains only the PK, ie P _K = {PK}
• c. as long as the set (1) P _{K is} not empty (P _K ≠ ⁣ {}) choose a component K from P _K and remove it from P _K , (2) P _{K is} empty (P _K ≡ {}) go to f ,
• d. For each (if any) subcomponent (UK) of K, examine whether it is (1) a true subcomponent, then add it to P _K (P _K = P _K ∪ UK), (2) is a logical subcomponent, then add add them to the set P _LK (P _LK = P _LK ∪ UK), add K to f _VK (UK) (f _VK (UK) = f _VK (UK) ∪ K)
• e. go to c.
• f. if P _{LK is} empty (P _LK = {}) then nothing can be tied to this platform component (error), otherwise P _LK contains the set of logical components of PK

step 3

• a. die Menge A_BK ist anfangs leer, d.h. A_BK = {}
• b. die Menge A_K enthält die noch nicht auf Bindbarkeit untersuchten Komponenten und enthält anfangs nur die AK, d.h. A_K = {AK}
• c. solange die Menge (1) A_K nicht leer ist (A_K ≠⁣ {}) wähle eine Komponente A aus A_K und entferne sie aus A_K, (2) A_K leer ist (A_K ≡ {}) gehe zu e.
• d. falls die Komponente A (1) ein Subtyp einer Komponente in P_LK ist, füge A zu A_BK hinzu (A_BK = A_BK ∪ A), sonst (2) echte Unterkomponenten besitzt, füge alle echten Unterkomponenten von A in A_K ein, sonst (3) auf der Plattform nicht bindbar (Fehler)
• e. die Menge A_BK enthält alle auf die Plattform zu bindenden Komponenten

The objective of this step is to determine the amount of application subcomponents A _{BK to be bound} . An exemplary embodiment is in 11 shown.
Input: Application component AK and P _LK
Output: the set A _BK (the application subcomponents to bind)

• a. the set A _BK is initially empty, ie A _BK = {}
• b. the set A _K contains the components not yet examined for bondability and initially contains only the AK, ie A _K = {AK}
• c. as long as the set (1) A _{K is} not empty (A _K ≠ ⁣ {}) choose a component A from A _K and remove it from A _K , (2) A _{K is} empty (A _K ≡ {}) go to e ,
• d. if component A (1) is a subtype of a component in P _LK , add A to A _BK (A _BK = A _BK ∪ A), otherwise (2) has true subcomponents, add all true subcomponents from A to A _K , otherwise (3) not bindable on the platform (error)
• e. the set A _BK contains all components to be bound to the platform

Step 4

• a. die Menge A_BC ist anfangs leer, d.h. A_BC = {}
• b. solange die Menge (1) ABK nicht leer (ABK ≠⁣ {}) ist, wähle eine Komponente A aus ABK und entferne sie aus ABK, sonst (2) ABK leer ist (ABK ≡ {}) gehe zu f.
• c. füge A in die Menge A_Cluster ein (A_Cluster = {A})
• d. füge alle mit A über Kontrollflüsse (requires/provides) oder Datenflüsse (in/out/inout) verbundene Komponenten in A_Cluster ein, entferne diese Komponenten aus A_BK, A_Cluster enthält damit alle mit A verbunden Komponenten (transitive Hülle)
• e. füge A_Cluster in A_BC ein und gehe zu b.
• f. die Menge A_BC einhält alle zusammenhängenden Cluster der Applikationskomponente, wobei jeder Cluster aus auf die Plattform bindbaren Komponenten besteht

The objective of this step is the determination of immediate binding constraints (binding constraints, especially due to necessary local control ← and data flows - locally means here on the same processor and thus in the same memory (on-board)) by clustering, ie from A _BK the amount of binding Determine cluster A _BC . An exemplary embodiment is in 12 shown. A cluster is an application component that must be bound to the same platform component.
Input: A _BK (the application subcomponents to be bound)
Output: A _BC (set of clusters of application subcomponents to bind)

• a. the set A _BC is initially empty, ie A _BC = {}
• b. as long as the set (1) ABK is not empty (ABK ≠ ⁣ {}), select a component A from ABK and remove it from ABK, otherwise (2) ABK is empty (ABK ≡ {}) go to f.
• c. add A to the set A _cluster (A _cluster = {A})
• d. insert all components connected to A via control flows (requires / provides) or data flows (in / out / inout) into A _cluster , remove these components A _BK , A _cluster contains all components connected to A (transitive shell)
• e. insert A _Cluster in A _BC and go to b.
• f. the set A _BC includes all contiguous clusters of the application component, each cluster consisting of components bindable to the platform

Step 5

• a. Erzeuge S, mit zwei echten Unterkomponenten AK und PK
• b. solange die Menge A_BC (1) nicht leer (A_BC ≠⁣ {}) ist, wähle einen Cluster C aus A_BC und entferne ihn aus A_BC, sonst (2) leer ist (A_BC ≡ {}) gehe zu f.
• c. wähle aus C eine Komponente K aus, setzte die Menge M gleich f_VK(K)
• d. solange die Menge M (1) nicht leer (M ≠⁣ {}) ist, wähle eine Komponente VK aus M und entferne sie aus M, sonst (2) leer ist (M ≡ {}), dann ist es nicht möglich den Cluster C auf die PK zu binden (Fehler) oder falls bereits Cluster der Plattformunterkomponente zugeordnet wurden und diese potentiell auch auf andere Plattformunterkomponenten bindbar sind (durch andere Wahl in [d.(1)] oder [b.(1)]), dann kann durch back-tracking diese Wahl rückgängig gemacht werden und erneut versucht werden, C zu binden
• e. wenn die VK (1) genügend ungebundene logische Unterkomponenten besitzt, um alle Komponenten des Clusters C diesen logischen Unterkomponenten zuzuordnen, dann binde (verlinke) die Komponenten von C mit den entsprechenden logischen Unterkomponenten von VK und gehe zu b. (2) nicht genügend ungebundene logische Unterkomponenten besitzt, um alle Komponenten des Clusters C diesen logischen Unterkomponenten zuzuordnen, dann gehe zu d.
• f. S ist eine vollständig gebundene Systemvariante

The goal of this step is to determine an initial binding of the clusters to the platform. An exemplary embodiment is in 13 shown (for the graphic details of the two components see 10 and 11 ).
Input: f _VK () (mapping of logical components to their parent components),
A _BC (set of clusters of application subcomponents to bind)
Output: S (system variant consisting of two subcomponents AK and PK, whereby the AK is completely bound to the PK)

• a. Create S, with two real subcomponents AK and PK
• b. as long as the set A _BC (1) is not empty (A _BC ≠ ⁣ {}), choose a cluster C from A _BC and remove it from A _BC , otherwise (2) is empty (A _BC ≡ {}) go to f ,
• c. choose from C a component K, set the set M equal to f _VK (K)
• d. as long as the set M (1) is not empty (M ≠ ⁣ {}), choose a component VK from M and remove it from M, otherwise (2) is empty (M ≡ {}), then it is not possible the cluster C bind to the PK (errors) or if clusters have already been mapped to the platform subcomponent and they are potentially bindable to other platform subcomponents (by other choice in [d. (1)] or [b. (1)]), then This choice can be undone by back-tracking and trying to bind C again
• e. if the VK (1) has enough unbound logical subcomponents to map all components of cluster C to these logical subcomponents, then link (link) the components of C to the corresponding logical subcomponents of VK and go to b. (2) does not have enough unbound logical subcomponents to map all components of cluster C to these logical subcomponents, then go to d.
• f. S is a fully bound system variant

Step 6

• a. Überprüfung kumulativer nicht-funktionaler Eigenschaften, z.B. (1) Speicheranforderung: Jede gebundene Applikationsunterkomponente (A1, A2, ...) kann Attribute mit Speicheranforderungen (Stack, Heap, etc.) definieren. Die Speicheranforderung an die Plattform ist die Summe aller entsprechenden Speicheranforderungen der Applikationsunterkomponenten, die auf eine logische Plattformkomponente (siehe Schritt 5e.(1)) gebunden sind (Stack_Sum = Stack(A1) + Stack(A2) + ...). Die direkte Plattformvaterkomponente oder eine ihrer Vaterkomponenten kann eine maximale Speichergröße (z.B.: MaxHeap, etc.) definieren, sodass überprüft werden kann, ob überhaupt genügend Speicher für die Applikationskomponenten auf der Plattform zur Verfügung steht. Falls nicht genügend Speicher zur Verfügung steht, ist diese nicht-funktionale Eigenschaft nicht erfüllt und damit die Systemvariante ungültig (Fehler). Analog zu Schritt 5d.(2) kann ein back-tracking durchgeführt werden, um eine neue Systemvariante zu erhalten. (2) Lasten: Jede Applikationsunterkomponente AUK definiert einen lokalen Taskgraphen gemäß [1, 2] mit den Tasks T(AUK) = T₁, ..., T_n. Durch der Verbindung der AUKs entsteht ein globaler Taskgraph. Daraus lässt sich die Periode der entsprechenden Tasks ableiten. Sobald eine Applikation auf eine logische Plattformkomponente PFK gebunden ist (siehe Schritt 5e.(1)) lassen sich die Ausführungszeiten der Tasks auf dieser PFK ermitteln. Die Last eines Tasks T ist dann das Verhältnis zwischen Ausführungszeit und Periode (Last(T) = Zeit(T, PFK)/Periode(T)). Die Menge der auf einer PFK gebundenen Tasks ist gegeben durch die Menge aller Tasks der gebundenen Applikationskomponenten (T(PFK) = T(AUK1) + T(AUK2) + ...). Somit lässt sich die Gesamtlast einer PFK durch Summierung aller Teillasten ermitteln (Last(PFK) = Last(T1) + Last(T2) + ...). Ist diese Last größer 1, so ist die PFK überlastet und die Systemvariante ungültig (Fehler). Analog zu Schritt 5d.(2) kann ein Back-Tracking durchgeführt werden, um eine neue Systemvariante zu erhalten. Es ist darauf hinzuweisen, dass kumulative Eigenschaften bereits in Schritt 5e. als zusätzliche Bedingung überprüft werden können (d.h. genügend ungebunden logische Komponenten UND entsprechende kumulative Eigenschaft erfüllt). Dies kann von Vorteil sein, da sie sehr schnell überprüfbar sind.
• b. Überprüfung zeitlicher nicht-funktionaler Eigenschaften z.B. Analyse von WCETs (Worst Case Execution Times = Ausführungs/Durchlaufzeiten im schlechtesten Fall) und BCETs (Best Case Execution Times Ausführungs/Durchlaufzeiten im besten Fall) nach der Methode beschrieben in [1, 2], wobei das Verfahren an die in Anhang B beschriebene Modellierung angepasst wird: (1) die Plattformkomponenten definieren jeweils ein WCET und BCET Attribut, welche mit jeweils einer Evaluierungsfunktion verbunden sind. (2) diese Evaluierungsfunktionen besitzen als Eingabeparameter den Task T. Dieser Task T entspricht einem auf der Plattformkomponente gebunden Task. (3) Es existieren verschiedene Evaluierungsfunktionen in der Datenbank für die verschiedenen Scheduling Verfahren (z.B. RMS, TDMA, etc.) Nach der Berechnung der BCETs und WCETs wird die Einhaltung von Deadlines (Zeit zwischen zwei Ereignissen, z.B. von der Aktivierung eines Task bis zur Deaktivierung) und die Überschreitung der Periode durch die WCET eines Task (WCET muss kleiner als Periode sein) überprüft. Bei der Verletzung einer dieser beiden Eigenschaften wird (1) entweder: die Priorität (bei RMS) bzw. der Timeslot (bei TDMA) des Tasks erhöht und erneut Schritt [b.] durchlaufen, (2) oder: Analog zu Schritt 5d.(2) kann ein Back-Tracking durchgeführt werden, um eine neue Systemvariante zu erhalten. (3) oder: die Systemvariante wird als ungültig zurückgewiesen (Fehler).
• c. Überprüfung funktionaler Eigenschaften z.B.: Deadlock- und Lifelock-Freiheit, Erreichbarkeit von Systemzuständen. Basierend auf der formalen Beschreibung des Komponentenmodells (Prozessalgebra gemäß [3]) wird eine statische Analyse der Systemvariante durchgeführt, die mögliche Deadlock- und Lifelockzustän de identifiziert. Falls Deadlocks, Lifelocks existieren bzw. geforderte Systemzustände nicht erreicht werden, ist die Systemvariante ungültig (Fehler). Diese Analyse kann bereits (teilweise) vor Schritt 2 durchgeführt werden
• d. Wenn a., b. und c. erfolgreich durchlaufen sind, ist die Systemvariante gültig

In this step, the fulfillment of the functional and non-functional properties of the system variant is checked.
Input: S (fully bound system variant)
Output: S (valid system variant, ie fulfills the functional and non-functional properties)

• a. Review of cumulative non-functional properties, eg (1) memory requirement: Each bound application subcomponent (A1, A2, ...) can define attributes with memory requirements (stack, heap, etc.). The memory requirement to the platform is the sum of all corresponding memory requirements of the application subcomponents bound to a logical platform component (see step 5e (1)) (Stack _Sum = Stack (A1) + Stack (A2) + ...). The direct platform father component or one of its parent components can define a maximum memory size (eg, MaxHeap, etc.) so that it can be checked if there is enough memory available for the application components on the platform at all. If not enough memory is available, this non-functional property is not fulfilled and the system variant is invalid (error). Analogous to step 5d (2), a back-tracking can be carried out in order to obtain a new system variant. (2) Loads: Each application subcomponent AUK defines a local task graph according to [1, 2] with the tasks T (AUK) = T ₁ , ..., T _n . The combination of the AUKs creates a global task graph. From this the period of the corresponding tasks can be derived. As soon as an application is bound to a logical platform component PFK (see step 5e (1)), the execution times of the tasks can be determined on this PFK. The load of a task T is then the relationship between execution time and period (load (T) = time (T, PFK) / period (T)). The set of tasks bound on a PFK is given by the set of all tasks of the bound application components (T (PFK) = T (AUK1) + T (AUK2) + ...). Thus, the total load of a PFK can be determined by summing all partial loads (load (PFK) = load (T1) + load (T2) + ...). If this load is greater than 1, the PFK is overloaded and the system variant is invalid (error). Analogous to step 5d (2), back-tracking can be carried out in order to obtain a new system variant. It should be noted that cumulative properties already in step 5e. can be checked as an additional condition (ie enough unbound logical components AND corresponding cumulative property met). This can be an advantage as they can be checked very quickly.
• b. Review of temporal non-functional properties eg analysis of WCETs (Worst Case Execution Times) and BCETs (Best Case Execution Times execution / lead times in the best case) according to the method described in [1, 2], where the Is adapted to the modeling described in Appendix B: (1) the platform components each define a WCET and BCET attribute, each associated with an evaluation function. (2) these evaluation functions have the task T as input parameters. This task T corresponds to a task bound on the platform component. (3) There are various evaluation functions in the database for the different scheduling methods (eg RMS, TDMA, etc.) After the BCETs and WCETs have been calculated, deadlines are observed (time between two events, eg from the activation of a task to the Deactivation) and the exceeding of the period by the WCET of a task (WCET must be less than period). If either of these two properties are violated, either (1) the priority (in RMS) or timeslot (in the case of TDMA) of the task is incremented, and step [b.] Is repeated, (2) or: analogously to step 5d. 2) back-tracking can be performed to get a new system variant. (3) or: the system variant is rejected as invalid (error).
• c. Check of functional properties eg deadlock and Lifelock freedom, accessibility 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, which identifies possible deadlock and Lifelockzustän de. If deadlocks, Lifelocks exist or required System statuses are not reached, the system variant is invalid (error). This analysis may already be performed (in part) before step 2
• d. If a., B. and c. have passed successfully, the system variant is valid

Step 7

The goal of this step is to transform the verified system variant into a system table. An exemplary embodiment is in 14 shown.
Input: S _VER (valid system variant)
tf () (a transformation specification of components and attributes of the system variant in elements of the system table)
Output: ST (system table)
a. ST = tf (S)

references

• [1] Razvan Racu, Kai Richter, Rolf Ernst. Calculating Task Output Event Models to Reduce Distributed System Cost. In GI / ITG / GMM Workshop Methods and Description Languages for Modeling and Verifying Circuits and Systems, pages 1-10. Kaiserslautern, Germany, February 2004 ,
• [2] R. Henia, A. Hamman, 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 (2)

Automatic, model-based integration process a functional system architecture with a physical system architecture to an electronic system, in particular an avionics system, where the functional system architecture is a single application component includes and the physical system architecture individual platform components includes. An assignment of application components to platform components is made such that I. the assignment is complete II. Ensures the functional flow of the functional system architecture is III. the non-functional requirements for the entire system Fulfills become. The method is characterized by the following method steps: in The first step will be the specification of the functional system architecture as well as the physical system architecture provided, which have the following properties: I. Platform Components as well as application components form a hierarchy in which Subcomponents a structural refinement of the associated parent components represent II. By means of behavior extension of platform components As well as application components, these can be further connections, functions and attributes added become, III. the platform components have so-called logical Platform subcomponents as placeholders for later to be inserted application components on, in a second step, the set of logical Determines platform subcomponents of the physical system architecture in a third step is the amount of the physical system architecture determined to be assigned application components, the assignment of a Application component is allowed on a platform component, if I. an application component as a logical platform subcomponent the platform component exists, or II. An application component from a logical platform subcomponent of the platform component Behavior extension is derived, in a fourth step the set of clusters of application components is determined wherein a cluster comprises such application components, the same Must be assigned to the platform component, in a fifth step a first system variant by complete assignment of the clusters generated by application components on the platform components becomes, In a sixth step it is checked whether the generated system variant meets given functional and non-functional requirements; it falls exam Negative, are by change the assignment of the clusters to the platform components new system variants generated, until we have a valid system variant, in a seventh step the permissible System variant transformed into a system table for the electronic system becomes. Method according to claim 1, characterized in that that in the third step, if the assignment of an application component is not allowed on a platform component is checked, whether the binding of a parent component of the application component permissible is.