Background of the invention The invention concerns a method for enforcing an authorization, method for evaluating an authorization, use of a component framework for controlling a safety critical process and computer program product. A method for evaluation of an authorization is known from [EN 50129] or [IES 61508].

An interface describes a sub-set of the behavior of one or more software components. It is obtained by considering only the interactions between com- ponents that take place in the context of this interface, and by hiding all other interactions - component-internal interaction, interactions with third party components, or interactions implying the components under consideration but which are not part of the interface. A component is an encapsulated building block of software, exposing its functionality via a defined set of in- terfaces. It is said that a component implements an interface. It is said that an interface qualifies the component that implements it.

Interfaces are defined artefacts, i.e. a definition of an interface must exist independently of the components that implement it. The interfaces of components compliant to a definition are called the instances of the definition. The interface definition gathers the behavior common to all its instances. Interface definitions are considered under configuration control : changes to the definition are possible only according to a defined change management process resulting in a change in version.

Changes in behavior of an interface instance towards its definition shall be seen as a deviation. Especially, if an interface is changed compared to a former behavior, originally compliant to an interface definition, it shall be considered uncompliant unless the interface definition has changed accordingly too. Similarly, a component implements its set of interfaces loyally to their definitions, unless it is considered defect.

Components are defined in two steps: component definition and component instances. The component definition gathers the functionality common to all instances instantiating this definition. Component instances are differentiated from each other by different sets of data / internal states.

Like instances, component definitions are supposed under configuration management, i.e. they become a version : - If a component definition is changed in order to implement a new version of an interface definition, the version of the component definition shall change

- If a component definition changes, it shall be attributed a new version, even if it implements the same set of interfaces as before, with the same version number. This permits to differentiate, among others, between bug fixes.

For instance, a component definition may be the 'Software written to control Thales Points Version 2.2'. Two instances of this component definition could then be the controllers respectively for two different points of this type in two different stations.

A component composite is the combination of two or more instantiated components that yields a new component behavior. A component composition mechanism supports the creation of a larger structure by connecting components and the insertion or substitution of components within an existing structure. Since a composite behaves like a component it is versioned as well. A component composite, as well as components and interfaces, is defined in two steps: composite definition and composite instances.

A component part of a composite is defined as its sub-composite. The composite is said to be the container of the component. From the point of view of the composite itself, the interfaces of its sub-composites may be internal or external. From the point of view of the composite, Internal interfaces are those binding only sub-composites of the composite; external interfaces are those binding at least one component that is not a sub-composite of the composite.

A composite is univocally defined by its sub-composites and the binding of its internal interfaces (i.e. which interface of some sub-composite is expected to be bound to which other interface of another or the same sub-composite, respectively which interfaces remain unbound). Given the interface compati- bility restrictions already consequence of their definitions, defining the interface binding may not be necessary to reach unambiguousness. In that case, the interface binding may remain implicit without impeding the composite definition.

Software composition is very similar to assembling hardware. Hardware components usually are bound to each other via their hardware interfaces. Together, hardware components build up hardware assemblies.

A component framework is a set of executable software elements dedicated to the creation and execution of composites within a component model. While instantiated, components may be created and executed and reverse:

• Creation/instantiation : computer resources (like memory, threads, processes) are allocated and defined. Component instances are tailored out of persistent data. The binding is part of this step (it may be considered a step for itself but this is not necessary in this invention).

• Execution : the use of the previously allocated computer resources is allowed (e.g. processes or threads are allowed for execution, timers enabled, ...). Interfaces are allowed for invocation : the component calls to the interfaces of other components are forwarded.

• Stop: the calls to the interfaces of a component by other components are not forwarded anymore: interfaces are not allowed for invocation anymore. Computer resources may be frozen (threads, processes, timers, ...).

• Destruction/deinstantiation : data tailoring the instance may be persisted if required. Computer resources are freed (memory, thread and in our definition interface binding).

Modern frameworks usually are capable to access metadata associated to components or interfaces. Metadata associated to components or interfaces are defined as a set of information characterizing the definition or instances of components or interfaces, and available to the framework. Like for components and interfaces, metadata definitions and metadata instances coexist.

For instance, additionally to the already introduced version, the data of the company having produced a component may be defined in very detailed fields: date of release, name of the company, street number, street name, zip code. For each of those fields of metadata, a type has to be defined. In the company example, the names may be coded via strings, street numbers and zip-codes via constrained numbers. Another example is to qualify a component instance with its variant. In this case, the value of the variant field of a component instance is picked up out of an enumeration defined along with the component definition : the set of variants available for the component. A common variant for human machine interfaces is the language. In that case, the metadata definition is the set of languages potentially supported by a component, the value of the metadata field instance is the language actually supported by a given component instance.

Metadata may be frozen at component definition - see previous examples. Metadata may also be frozen at component instantiation. They may change all along the life of a component instance. In the examples above, company fields are likely to be frozen at definition. The variant field may be frozen at instantiation. Some metadata may remain dynamic during the life of the instance. The phone number of the hotline of the company may be dynamic in order to be able to change over the years. The instance may also publish some internal states: The language being supported by a component instance may vary along its lifetime according to the user it supports at a given moment. In that case, the framework may be capable to react on the changes of the metadata.

It is a common praxis that most metadata related to a component are published, i.e. provided to the other components, by the component itself. This means that to get access to the metadata of a component, an observing com- ponent needs to be bound to the publishing component by one of its interfaces (that publishes the metadata). Some metadata may be generated by the framework about the component. For instance, the framework may publish dynamic administration data related to a component like the date it was started, how much CPU or memory it consumes. Those metadata may be published by means of an interface added to the component instance by the framework at runtime (independently of the component definition). In this case, the frame metadata is considered published by the component itself. The framework may also offer an own interface that publishes those metadata generically, the component for which the metadata are retrieved being a parameter of the framework's interface. Finally, some frameworks also provide additional interfaces for the indirect access to the metadata published by a component, without having to be bound to the component. In this case, both methods of publication are available. From the point of view of safety- uncrit- ical component based design practices, defining the state of the art, component frameworks build composites based on the component definitions they store in their component database. Composite definitions are similarly made available to the framework. In a last step, the framework gets the instruction to build one instance of a composite (to instantiate it). Composite definition and instantiation instruction may be done separately or not, according to the framework.

The definition of the composite may be performed with different degrees of freedom. An explicit way to do is to associate in the composite definition each component with some metadata, especially the version. This way of doing, very defined, inhibits more dynamic practices, where only interfaces metadata, especially versions, are defined.

With the explicit way, one person defines how the components are gathered. One single human error may lead to an unwished configuration. No technical measure is provided by the framework to allow that a composite is created or started only if two persons came independently to the same specification of the composition. The explicit way is widely represented by Microsoft's manifest technic, as described in [MS MANIFEST]. The composite is named therein side-by-side assembly (§1.2). A composition is described by means of manifests (§4.2).

As described by the wikipedia page about 'Side-by-side assembly', the manifests were introduced "with Win98 second edition and Windows 2000" and maintained in later edition as "attempt to alleviate the problems that arise from the use of dynamic link libraries known as 'DLL Hell'. Such problems include version conflicts, missing DLLs, duplicate DLLs, and incorrect or missing registration. In side-by-side, Windows stores multiple versions of a DLL in the winsxs subdirectory of the Windows directory, and loads them on demand."

With implicit composition, composites are defined without defining the versions of components themselves (only interfaces). A component can be replaced by one of its evolutions (see below)- as long as implementing the same versions of interfaces. A component can be replaced by components with no relationship (e.g. components which are implemented with different algorithms, by different teams or companies, ....) as long as implementing the same interfaces with the same versions. Modern frameworks leverage the freedom of implicit composition to save the state of a component, stop it, replace it with a new version, initialize the new instance with the old state, and restart without interruption of service. If a framework is given the ability to automatically retrieve the most up-to-date version of component and composite at its disposal, it may autonomously upgrade software without interruption of service, a technic called seamless deployment. Seamless deployment is a key feature of the modern, highly available, IT systems for which component frameworks are designed. Typically, the upgrade of big websites is not noticeable for end users.

This freedom left to the framework permits to replace versions with a low administrative overhead. It happens at the cost of the unambiguousness of the configuration management. In big composites, several versions of sub- composites may be available with different versions of interface and it may be impossible to combine the most up-to-date version of each component without violating the version control of interface definitions. The framework has to choose between several local optima. The rules for choosing, or their consequences for the assembly, may not necessarily be transparent to all component designers. The risk brought-in by the ambiguity, however, is judged low enough by the companies implementing continuous deployment because they size the quality measures prior to composite definition and definition of the composite instructions according to their loss in case of problems due to an ambiguous deployment. They judge the probability of defect due to incompatible set-ups low enough to be accepted. In case such a bug is detected, the software is seamlessly restarted with a former version while the source of the bug is searched and a new version of the component solving the problem is prepared.

The implicit way to define deployments is currently the industry trend. For instance, in [JBOSS2002], explicit dependencies are addressed. All over the extract, the composing, binding etc. is defined. On Page 40, explicit binding as (per version of components) is introduced as optional. At no place, a verification of the allowance of a binding, as specified by an instance independent from the binding specifier, is defined. In [JBOSS2016], explicit dependencies are not presented anymore: Instead Chapter 3, § 3.1.6. Class Loading Precedence, presents how the framework performs automatic component identification and rules about some ways of avoiding ambiguities are presented - for instance running several versions at the same time in a framework. Here, as for [JBOSS2002], a verification of the allowance of a binding, as specified by an instance independent from the binding specifier, is defined at no place.

Although very high levels of quality may be achieved by single companies, the ambiguity associated to implicit composition is not acceptable in a safety critical context, where errors may lead to the loss of human lives: legal frames demand the evidence that no hazardous errors will happen before the deployment - without bargain about cost and benefits, or try and withdraw strategy. Also, an important driver of modern safety norms is that somebody shall respond about organizational risk - the so called traceability. The reason is that industrial history shows that room for unclear responsibilities is a frequent ingredient of accidents. For instance, in [ORG-ACCID], the Piper Chieftain Crash at Young example presents a situation about conflicting goals. With current state of practice as defined by [EN 50129], only systems (and components) for which a safety manager responds shall be deployed in the European railways, as documented in a safety case. The safety case is a document or set of documents that engages in a traceable way the responsibility of its author. It is associated to a univocal identification of the system it covers. Typically, the safety case defines further system components and responsibilities - sub-components of the safety case's scope that need their own safety case or systems outside the safety case, that the safety case presupposes to remain valid.

Lastly, safety norms enforce that the quality of work-products influencing the safety of a software (executable, parametrization) depend on more than one person by introducing independent tests, quality criteria for these tests like code coverage as for instance in [IEC 61508]. In this document, independency of safety verification is addressed in Part 1 chapter 8 p.54 to 58. An example of quality criteria for verification is the definition of criteria Rl to R3 in part 3.

The requirement for traceability in system development and reproducibility of deployment, incl. loyalty to approved configuration, excludes a component being claimed compatible with an interface only. It has to be compatible with components also. Therefore, although safety critical development organization rely on high quality standards that would "probably" enable that "nothing happens", state authorities are reluctant to authorize such generic validations at interface level.

These principles are presented in detail [DEV-SAFE-SW]. In §18.4, the main stakes are presented (protecting unauthorized changes, managing configuration, ensuring that the right software is downloaded, ...). §18.5.1 presents the technical requirements set to field downloads such as protection from inadvertent downloading, determination of inappropriate software loads. §18.5.3 emphasizes the insurance that the software downloaded has been approved by the certification authority, also under consideration of the hardware that should host is. It relies ensuring that the part number of the software is confirmed after the load.

This is very much similar to the practices currently used in the rail domain.

For instance, for Thales, current product generation bases on the TAS Platform as its safety critical middleware. This layer comprises

- Hardware boards derived from 'non-safe' embedded products after specific hazard analyses

- An operating system layer, incl. drivers.

- Start-up and cyclic on-line tests ensure that no latent failure lies in the system

- A home-made fault tolerance layer (voting, monitoring of real-time behavior) insulates the safety critical software (called thereafter the application) and the lower (hardware and OS) layers, making sure that failures express only in the API presented to safe application, and in defined manners that the application can process safety (missing message, detected delay, ...)

- The Unix memory protection between processes of a same computer is used to avoid that failures of one module (for instance erroneous pointers) of the application impacts the others other than via missing messages or faulty messages on voted message queues.

- Each application module is designed to process safely and at any time delayed (missing) messages or disappearing neighbor processes (which result in disrupted message flows).

- A safety critical (themselves considered part of the application) communication stack adds message protection for communication with neighbor safe computers in such a way that the receiver can detect any fault taking place during communication (and some faults have led to the genesis of the message)

In former TAS Platform generation (1.x. x), the OS used was a proven in use real-time SUN-OS derivate, Chorus. This kernel was little enough to have been assessed for itself. Such OS are nowadays not supported anymore. Therefore, in recent years (2.x.y), Linux was introduced to benefit from new hardware generations. Its wide deployment also insures some level of quality - counterbalancing its lack of traceability, for instance due to its frequency of upgrade. Linux could be introduced based on the barriers towards its failures built in the home-made fault tolerance layer. This fault tolerance layer, had to grow mature enough on the previous little, "controlled" OS, to convince the safety authorities.

Once the level of maturity required to convince the safety authorities reached, TAS Platform 1.x concepts were improved according to the experienced gained in the past decade and the new requirements set by the introduction of a COTS OS. It led to the definition of TAS Platform 2.x. At the time the TAS Platform 2.x development was launched, frameworks were established on servers of a size not fitted to embedded systems. The concept maturation for TAS Platform 2.x had not yet been completed. The introduction of a framework seamed so remote it was not even evoked during the feature definition.

As a consequence, TAS Platform 2.x proposes some remote download of application software via proprietary protocols very close to TAS Platform 1.x and based on the disk partition concept - still valid for Linux. The version control between partitions and/or application modules remains an explicit responsibility of each application module, without transverse support.

Partition based upgrade requires a full restart of the TAS Platform computing node - and the interruption of all application modules hosted on the computer. This refrains from hosting more application modules on one safe computing node, although last generation hardware boards would allow it. A pro- prietary software push (module wise upgrade in the background without reboot of the platform) is currently not intended for TAS Platform 2.x because too expensive to develop.

The current development status is that, to address the obsolescence of TAS Platform 1.x, safety critical applications (axle counters, field element controllers, interlocking, movement authority units) introduce TAS Platform 2.x. Due to the design changes implied by the technically enforced version checks, and the lack of central technical support for it, as well as the necessity to stop the full system, this proprietary remote download will not be supported by all products in the first step.

As a summary, modern component frameworks and their benefits face suspicion in safety critical contexts because:

• The definition of composites and instantiation instructions may be subject to human errors,

• To benefit from their most advanced feature, the ambiguity left in the definition of composites is contradictory to the very claim of preventing accidents

Object of the invention

It is therefore an object of the invention to provide a method for evaluating the authorization of a safety relevant component, i.e. whether the execution of a component is authorized in a safety relevant context, as defined by approval authorities in charge. It is therefore an object of the invention to provide a method for enforcing this authorization.

Ultimately, the combination of these inventive methods enable to host a multitude of application modules on one computing node while preserving or even reinforcing the safety levels reached by current practices. Combined with security features not addressed by this patent application, the invention is an enabler for safety capable cloud computing. Description of the invention

This object is solved by methods according to claims 1 and 17, the use of a component framework according to claim 18 and a computer program product according to claim 19.

The current invention presents enhancements in order to enable dynamic assembly by component frameworks, while excluding the risk associated to ambiguity or human errors in composition, as defined by current state of the art in safety practices.

In order to describe the invention, several new definitions are taken about safety processes:

An approval authority is defined herein as any person or organization in charge of issuing a safety authorization prior to the deployment of a safety relevant control system. Preferably the approval authority is independent from the developers implied in the development of the components to be authorized or of a composition of the composite comprising the component to be authorized.

In this invention, the authorization or refusal delivered by an approval authority is formalized as an approval statement, each approval statement comprising a recommendation and a scope.

The recommendation defines whether its associated approval statement enables or inhibits the deployment. A recommendation can be "approved" or "refused":

• Approved recommendation : The approval authority tolerates the deployment of a composite for a given scope.

• Refused recommendation : The approval authority has explicitly defined that a composite shall not be deployed in a specified scope. A recommendation always has a start date - may it be its date of delivery - and may be limited in time, or not. A recommendation qualifies a scope.

An approval statement is said to be approved or refused if its recommendation is approved or refused.

The scope of an approval is the formalization of the context and conditions for which the recommendation is issued. The scope of an approval associates components, interfaces and bindings with the safety relevant metadata that define these context and conditions. As several composites can be considered, lists of metadata can be described by use of generic descriptions. Like bindings, scopes can make use of implicit binding.

Given a composite instance and a scope, the scope is said to cover the composite instance if all component instances and their metadata constituting the composite instance match the metadata specified by the scope. Note that for an approved approval statement this means that all interfaces connecting sub-composites of the composite are covered by the scope. Interfaces of sub- composites foreseen to be bound outside the composite are not necessarily covered by the scope.

Safety relevant metadata, the one considered for this invention, are defined as any metadata that approval authorities may judge relevant to determine whether instances of components or interfaces can be composed together in a safety relevant application.

- The component versions of the sub-composites of a composite are, in a safety relevant environment, a restricting element of component composition. The sole compatibility of the interfaces implied in the component is not sufficient.

- Variants of components, as they tailor the composite's behavior, may influence an approval statement.

- The mandatory character of the binding of an interface, as seen from the perspective of the component definition, may influence an approval statement: while defining a component, a designer may tag which interfaces must be bound before the component is started, i.e. which interfaces must have a partner unless he cannot guarantee the safety of his component. This is true also while defining a composite, for external interfaces: the designer may not know yet in which composite his own composite will be inserted. But he/she can determine that some interfaces must have found partner components before his/her own composite or its components are allowed to execute.

The mandatory character of a sub-composite may be defined : if a sub-composite is mandatory for its composite, the composite may lose its authorization if the composite cannot be started or is stopped. If the sub-composite is optional, the composite may remain active without its sub-composite.

Component of interfaces may be associated with hierarchy levels.

For instance, some components may be dedicated to safe transport protocols (lower layer) while others deal with control and automation (upper layer). A scope may define the hierarchy levels it expects from the components that may be bound to its external interfaces.

The life-cycle of applications and components in safety- related domains is supposed to be divided in operational phases of different safety relevance. The operational phases and their safety relevance are supposed to be defined by approval authorities (e.g. Federal Railway Office) according to criteria not scope of the invention. Exem- plarily, following life-cycle phases may be supposed : Hot phases of a system's life-cycle are those in which it delivers at least one safety relevant function, i.e. safety of life is engaged. Typically, as soon as a train moves in an area controlled by an interlocking/movement authority unit, especially with passengers, the system is in a hot phase. Cold phases are those during which the system provides no safety relevant function - for instance when the system is being commissioned without train movements, e.g. during some maintenance sessions for which the traffic is stopped.

Warm phases are those during which the system does perform some safety relevant functions, but not in full extend. The approval authority is aware of it, acknowledges the necessity, and allows operation under restrictions. Such phases typically comprise field system test with train movement. Special measures are taken in order to ensure the required safety of the operations - drivers with enhanced skills, specific test organization, only test cases are driven, no passengers or freight trains, etc.

The invention relates to a method for the evaluation of an authorization of a component instance, i.e. whether the execution of a component instance within a component framework in a safety relevant context is authorized by an approval authority, the method comprising: providing the information necessary for the evaluation in a form suitable for automated processing by software; the method comprising : providing a list of approval statements each comprising a recommendation and a scope, wherein the scope is specified by means of metadata; providing an approval control function with access to the list of approval statements; carrying out an approval control by means of the approval control function.

Thus, according to the invention approval statements are provided comprising metadata (e.g. version, variant, life cycle, bindings etc.). This enables the approval statements to be processed by computer and to be available in any arbitrary number and for an arbitrary number of component instances at an arbitrary number of computers. The approval statements are preferably issued by an approval authority. Preferably the component instance to be executed is a sub-composite of a first composite instance. In this case the wherein the approval control function evaluates the component instance as being authorized only if the approval control function finds an approval statement in the list of approval statements, which fulfills both : the scope covers the composite instance and the recommendation is "approved", wherein the scope is said to cover the composite instance if the metadata of all component instances and interface instances of the first composite instance match the metadata specifying the scope.

The composite instance comprises interface instances and component instances which in turn are qualified by metadata. With the present invention the metadata of the instances can be easily compared with the metadata of the approval statements, thus providing an easy and reliable method to evaluate whether a component instance is authorized or not.

The approval control function checks whether composite instantiations are covered by at least one valid approval statement and in which context - especially the life-cycle phase. The approval control function may access the metadata of composite instantiations either directly or via the framework, according to their method of publication. According to the success or failure of checks, the approval control function may allow or forbid a change of components in life-cycle phase. If necessary, the approval manager may enforce, or lead the framework to enforce a stop of the component.

In a preferred variant, the first composite instance is a sub-composite of a further composite instance, wherein the approval control function evaluates the component instance as being authorized only if the approval control function evaluates the further composite instance as being authorized by the approval authority. In case the composite instance (here: first composite instance) which contains the component instance to be evaluated is contained in another composite instance (here: further composite instance) it has to be ensured that the first composite instance which contains the component instance to be evaluated is compatible with other sub-composites of its common container (further composite instance).

It is preferred that the approval control function evaluates a component instance as being authorized only if the approval control function determines that the list of approval statements does not contain an approval statement, which fulfills both : the scope covers the component's composite and the recommendation is "refused".

Further it is preferred that the approval control function evaluates a composite instance as being authorized only if the approval control function determines that the list of approval statements does not contain an approval statement, which fulfills both : the scope covers the composite's subcomponent and the recommendation is "refused".

The metadata of the interface instances and the component instances qualify the interface instances and the component instances and are required for evaluation. In a preferred variant, the metadata of the interface instances and of the component instances are advantageously provided to the approval control function by means of the component instances themselves.

In a special variant the approval control function is implemented in an approval manager, wherein the approval manager is a component instance. The approval manager can be added to existing frameworks. In this case the used framework does not comprise an approval control function.

Alternatively the metadata of the interface instances and the component instances can be provided to the approval control function by means of the framework, for instance because the approval control function is hidden by the framework, or is a part of it, and does not "see" the components.

In a special variant the approval control function is implemented in the component framework. I.e. the component framework comprises an approval control function.

In a preferred variant the approval control function controls metadata of components and/or interfaces which are deemed to be required by the approval authority, wherein the metadata controlled by approval control function in particular characterize at least one of: component definition, interface definition, component version, interface version, component variant, interface variant, the mandatory character of an interface or a sub-component, the life- cycle phase in which a component is or in which the components implied in an interface are, and hierarchy level of components implied in an interface.

It is preferred that the approval control function comprises version control functions (in particular a component version control function). Accordingly the metadata of the scope preferably comprise the version of the component's definition. Nevertheless, it is also possible to define a scope, which is "refused" independently of its version, e.g. for composite instances which are only permitted during maintenance. In this case no version control is required. A version control comprises checking out whether components and/or interfaces to be connected with each other are approved for each other. For version control the scope comprises version-numbers, wherein the version control checks whether the version number qualifying the component to be used and the version number of the scope of approval it is compared to comply with each other. Metadata qualify a hardware component and thus they also qualify a hardware composite. In a preferred variant a hardware component and its characteristics are made available to the approval control function by providing a substitute software component comprising metadata formalizing the characteristics of the hardware component. E.g. in case of an interlocking controlling a (real) train station or an area of a station, life-cycle phases may apply (from an operational point of view) to the real system : a station for example may be under commissioning, maintenance, operation. In this case, the interlocking software component may follow these life cycle phases.

In a special variant the scope further comprises the metadata of the substitute software component, in particular to enable the validations of authorization concerning the relationship between hardware sensors and software components taking the hardware-sensor as input, or concerning actors controlled by software components, or concerning computing facilities hosting the software components, or any combination of those.

The hardware component can be part of a hardware assembly, wherein the hardware component itself is a further hardware assembly of further hardware components, and wherein for the further hardware components further substitute software components are provided. A physical assembly is a composite of hardware-components, the physical assembly itself being qualified by metadata, e.g. life-cycle phases, hardware version, hardware variant. According to the invention it is advantageous if the substitute software component of the hardware assembly is made available to the framework as a composite of the further substitute software components.

If two hardware components are physically interfaced to each other, in particular within a hardware assembly, wherein for each hardware component a substitute software component is provided, it is preferred that for the physical interface between the hardware components a substitute interface is provided, wherein the substitute software components of the hardware components are interfaced by means of a substitute interface, and that the substitute interface is made available to the approval control function.

It is preferred that a relationship of hierarchy or equivalence exists between fields and/or values of the metadata, wherein this relationship is known by the approval authority and is used by the approval authority to define the scopes of approvals, characterized in that this relationship is available to the approval control function and is used to assess the bindings according to the intend of the approval authority. For instance the following relationships may exist:

• For the field "life-cycle phase" any configuration approved for 'operations' may also implicitly be allowed for 'maintenance'.

• If versions are hierarchized in several fields (e.g. x.y.z), the last field may be chosen so that all versions equal but for the last field are compatible, by definition of the approval authority. For instance, 1.4.2 may be compatible to 1.4.3. In that case, the scopes of approval may elude the last field, specifying only 1.4 or 1.4.*.

This is a specific case about how the approval control function is provided with its scopes.

In accordance with the invention multiple approval authorities can provide approval statements, wherein for each approval authority an evaluation of the authorization according to the invention is carried out. For instance, according to CENELEC, a system shall be deployed only after successful validation by a first approval authority and successful assessment (of the validation) by a second approval authority and successful approval (of the assessment) by a third approval authority. In order to evaluate the system's authorization, the number and type of the required approval authorities depends on the safety insurance processes implemented by a company, required by a norm or a legal frame and are determined by the deployment configuration manager according its legal duties.

The enforcements ruling their relationships are implementation matter. For instance, the approval control function may require an approved recommendation from all approval authorities involved in the authorization. As each approval authority specifies its approval statement independently of the other, and the evaluation of the approval function delivers a final authorization only if an authorization could be delivered for all approval authorities, it permits to mitigate human errors in the specification of the scopes of approval.

Lastly, as the approval control function is software, supposed of the quality suitable for safety critical contexts, it is not subject to the human errors a human verifier would be prone to with a local verification procedure' based on paper descriptions of expected configurations. So this particular implementation brings in an improved safety towards paper-based verification.

In a preferred variant a validity time window is provided for the authorization, e.g. max. 5 years from the first day of authorization on.

It is preferred that the approval control function controls the authorization of a component prior to the start of the component.

In a preferred variant of the inventive method the approval control function controls the authorization of a component, when the metadata implied in the authorization of the component have changed, and the authorization is withdrawn : if the authorization is not valid anymore; in particular if the authorization is not valid anymore and no new valid authorization could be found. A preferred variant provides that several composites are evaluated to be authorized if, once composed together, the resulting composite is covered by an approved recommendation

Accordingly a preferred variant provides that several composites are evaluated to be refused together if, once composed together the resulting composite is evaluated by the approval function to be refused.

The approval control function preferably evaluates a composite to be authorized if it evaluates its subcomposites as being authorized, provided the composite is fully covered by the union of the parts of the composites. I.e. the approval control function evaluates a composite as being authorized if partial authorizations are issued for parts of the composite.

Further, the approval control function preferably evaluates a composite to be refused, if it evaluates a partial combination of components of the composite as being refused

The present invention also relates to a method for enforcing technically an authorization or refusal of deployment of a component instance to be executed within a component framework in a safety relevant context, wherein the evaluation of the authorization is carried out by using a method as described before, and wherein a consequence concerning the operation of the safety relevant component is preferably carried out automatically in dependence of the authorization or refusal. Thus an autonomous control (independent of a maintenance engineer) of a safety relevant component is realized. For instance, in case of an evaluated refusal (refused recommendation) the refusal information is not (only) shown to the maintenance engineer, but a required action can automatically be triggered (enforced), like stopping the component. Similarly, in case of an approved recommendation, the component may be started automatically. The framework preferably manages the component instance via a composition mechanism.

In a preferred variant the approval control function evaluates and/or enforces the authorization of a component prior to the start of the component, or when the metadata implied in the authorization of an already started component have changed, wherein the authorization is withdrawn if the authorization is not valid anymore; in particular if the authorization is not valid anymore and no new valid authorization could be found or, or when the metadata implied in the authorization of a not yet started component have changed, wherein the component is started if a valid authorization could be found.

The invention also relates to the use of a component framework for controlling a safety critical process, wherein an approval control function is provided for evaluating whether a component instance is authorized or refused. In particular the inventive method is advantageously used if an old component shall be replaced by a new component.

Further the invention concerns a computer program product directly loadable into an internal memory of a digital computer comprising software code portions for carrying out the afore described methods.

Further advantages can be extracted from the description and the enclosed drawing. The features mentioned above and below can be used in accordance with the invention either individually or collectively in any combination. The embodiments mentioned are not to be understood as exhaustive enumeration but rather have exemplary character for the description of the invention. Drawings

The invention is shown in the drawing. FIG. 1 shows the structure of a composite.

FIG. 2 shows the structure of a framework according to the state of the art. FIG. 3 shows the inventive method by using a framework comprising an approval control function.

FIG. 4 shows the inventive method by using a framework with approval control function and an approval function as add-on.

Fig. 1 shows components A, B, C, D, E, F, G, wherein components A, B, C, D, E are sub composites of a first composite Z and implement internal interfaces II and external interfaces 13. The components C, F, G are sub-composites of a second composite Y and implement internal interfaces 12 and the external interfaces 13. The first composite Z and the second composite Y in turn are sub-composites of a further composite X. The external interfaces 13 of the first and second composite are internal interfaces of the further composite X. The composite is defined by component instances required as sub- composites and the bindings between the sub-composites with interface versions. The components are defined by its interfaces and their versions.

Fig. 2 shows a framework 1 according to the state of the art, i.e. without approval control function. The framework comprises a composition mechanism 2 to which definitions of the composites are fed. The framework 1 further comprises a component registry 3 to which definitions of the components are fed. With the aid of the definitions the composition mechanism 2 creates the composites by binding the components. According to the state of the art the composites are then used for a composite application 4.

In fig. 3 a safe component framework 1' is shown which includes an approval control function 5 and a registry 6 of approval statements. According to the invention a list of approval statements 7 is provided by an approval authority. Each approval statement comprises a scope (specified by means of metadata) and a recommendation defining whether the approval authority tolerates the deployment of a specific composite for the given scope. The approval statements are fed to the registry 6 of approval statements to which the approval control function 5 has access.

The composition mechanism 2 sends a request for approval for an intended composite to the approval control function 5. The approval control function 5 attempts to map bindings to valid scopes of approval of the components of the intended composite by carrying out an approval control.

In case the approval control function 5 finds an approval statement in the list of approval statements 7 with a scope whose metadata match with the metadata of all component instances and interface instances of the intended composite instance, the approval control function 5 evaluates the intended component instance as being authorized, allows the creation of the respective composition by the composition mechanism 2 and starts the composite application. In case no approval statement is found which fulfils the above mentioned requirements, the creation and the application of the composite are inhibited.

In fig. 4 another variant of the inventive method is shown using the framework without approval control function 1 known from the state of the art. In addition to the framework 1 without approval manager function shown in fig. 1 an approval manager 8 is used. In this case the approval control function 5 and the registry 6 of approval statements are implemented in the approval manager 8 and are not part of the framework 1. This enables to carry out the inventive methods for safety relevant applications even with frameworks 1 without approval control function. The composition mechanism 2 of the framework 1 without approval control function creates a composition and sends a request for start to the composite application 4 which in turn sends a request for allowance to the approval control function 5. Again the approval control function 5 checks the approval statements of the registry 6. In case an appropriate approval statement is found the approval control function 5 initiates the start of the composite application 4.

Literature

[DEV-SAFE-SW] Developing safety-critical software, A practical guide for aviation software and DO-178-C compliance

Leanna Rierson; CRC Press, 2013,

ISBN : 978-1-4398-1368-3

[EN 50129] European standard, EN 50129, Feb 2003

Railway applications - Communication, signalling and processing systems - safety related electronic systems for signalling.

[IEC 61508] International Electrotechnical Commission norm 61508

Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems

April 2010

[JBOSS2002] JBoss Administration and Development

Scott Stark, Marc Fleury, JBoss Group

Sams Publishing, 2002

ISBN-10: 0672323478, ISBN-13 : 9780672323478

[JBOSS2016] https://access.redhat.com/documentation/en- US/JBoss_Enterprise_Application_Platform/6.2/html/De velopment_Guide/chap-Class_Loading_and_Mod- ules.html#Module_Dependencies

[MS MANIFEST] https://msdn.microsoft.com/en-us/li- brary/dd408052°/o28v=vs.85%29.aspx

[ORG-ACCID] Managing the risks of organizational accidents

James Reason

Taylor & Francis Ltd; 15. December 1997)

ISBN-10: 1840141050, ISBN-13 : 978-1840141054