Method and component for providing customized applications in industrial automation component

Abstract

The invention relates to a method and a component for providing customized applications in industrial automation components (A1, A2), each of which has a plurality of automation components (IED), in which, for each industrial automation component (A1, A2), it is provided that a commercial application is loaded from a common application store (MP), in particular an application store (application store), a commercial application is loaded from a local application repository (H1, H2) onto a plurality of industrial automation components associated with the local application repository (H1, H2) and run there, and transmitted into at least one local application repository (H1, H2-"center"), where the commercial application is loaded from the local application repository (H1, H2) onto the plurality of industrial automation components associated with the local application repository (H1, H2). In this case, the customized application is stored in one of the local application stores (H1, H2) and provided to automation components associated with the local application stores (H1, H2) for downloading and use, in which the customized application transmits values from the local application stores (H1, H2) to the other local application stores (H1, H2) and is provided to automation components associated with the local application stores (H1, H2) for downloading and use. H2) for downloading and use of an automation component (IED) associated with a plurality of components (1, 2, 3). Through the proposed center-to-center transmission method, even for applications that are not distributed by official markets, a high-requirement multi-tenant architecture and the most advanced user authority management are also achieved.

Description

Background Art

[0001] Automation components in industrial automation systems, such as programmable logic controllers and other microprocessor-controlled devices, are programmed with control programs, operating and monitoring programs (HMI – Human Machine Interface), and other applications. Traditionally, this involves transferring the application or automation program (or "app" for short) to a prepared device (e.g., one that provides firmware, an operating system, a virtual machine, or other runtime environment) and executing it.

[0002] In principle, this also applies to new industrial edge devices, which are computers or servers that are connected not only to automation networks but also, optionally, to public networks (e.g., the Internet). These computers or servers typically do not directly process industrial processes or procedures, but rather, for example, provide computing power, serve as a link between public and private networks, and undertake other, for example, centralized, tasks. Applications are also required for these devices, which are typically transferred to one of several packaged runtime environments (container runtime environments) in the form of containers (e.g., so-called Docker containers) and executed there.

[0003] While in the typical case of automation technology applications or other software are created and provided by an engineering system, which usually has direct access to the devices to be programmed, such as programmable logic controllers or HMI devices, third-party software is increasingly used today, e.g. from commercial providers or service providers, which is not directly connected to the automation network or the devices to be programmed.

[0004] In consumer technology, especially in mobile radios and tablets, applications are obtained from network-based servers, so-called "app marketplaces" (e.g., Apple App Store, Google Play Store, Microsoft Store, etc.). Besides user convenience, this solution offers the advantages that stored applications are generally checked, protected against tampering by signatures, certificates, and other mechanisms, and updates can be easily provided. For application providers, this centralized offering, i.e., an app store, offers the advantage of being able to manage sales and distribution using a single platform. This centralized offering provides users with a degree of control over which clients download, run, and update which applications.

[0005] These advantages are applicable in the context of industrial automation components; however, the industrial sector places higher demands on software security and availability, for example. Therefore, unlike solutions in the consumer sector, industrial devices, especially EDGE devices, are typically not "downloaded" directly from public application stores. Instead, the provided or acquired software or the applications to be used are loaded into the local application repository of the customer (more precisely, the operator of the automation component) and thus provided locally.

[0006] Here, the term "tenant" is generally used, instead of belonging to a customer or operator, to refer to the organizational unit that acquires or licenses an application and runs it once or on multiple devices in an automation assembly consisting of multiple devices (automation components) according to the licensing conditions. Whenever the terms customer, operator, etc. are used below, a so-called tenant is generally understood to be an economic or organizational unit.

[0007] The concept has proven successful for commercial applications provided by any provider of application software for multiple customers (tenants) or for commercial applications that should be loaded onto multiple devices by at least one or a few customers. However, the described distribution method also has disadvantages for application-specific programs and applications that are specifically adapted to a specific customer or application scenario, or are still in the prototype phase and not yet commercially available. Each modified version, prototype, etc., must be made available through an app store, and then undergo a thorough review and certification like a commercial application, and integrated into the distribution mechanism. Special measures must be taken to ensure that prototypes, etc., are not visible or available to all users or market participants, but only to specifically addressed automation components or specifically identified customers or tenants. Customers often also wish to create their own applications that should not or must not be made available through public app stores. While it is theoretically possible to build a customer's own app store, this is complex, or at least expensive, and also requires that the customer's own device, or at least a local "hub" (i.e., local application repository), must be connected to more than one app store, which is often impractical or undesirable.

[0008] An alternative approach is to transfer the individual ("customized") applications directly to the device to be programmed, for example, via direct data transfer or using a storage medium such as a USB stick, bypassing the app store solution with the help of so-called side channels, also known as "sideloading." However, this option should generally be disabled in industrial devices to meet security requirements. Furthermore, this often requires direct physical access to the device or at least to the local automation network, and this approach is complex when multiple devices are to be supplied with the proposed application.

[0009] In industrial environments, it is common practice not to provide automation components, such as industrial edge devices, programmable logic controllers, operating and monitoring devices, with applications (software) directly from a public application repository, such as an app store or marketplace. Instead, "commercial" applications ("applications") are first loaded from the public application repository into a so-called local application repository ("local hub") and then forwarded from there to the local, i.e., "local" automation component associated with the local application repository, thereby making them available locally. The term "local" with respect to the application repository does not mean that the application repository must be physically run locally, i.e., run in the same automation network as the associated automation component ("hosted"), but that it is provided to multiple automation components, preferably to a limited number of automation components associated with it. For example, the local application repository (hub) itself can be provided by a provider, for example, on the internet, in the cloud, or elsewhere, for example as a cloud-based service, but is a "local" application repository (local hub) due to its association with a specific automation component, such as a plant or production plant. Data transmission between the "local" application repository and the associated automation component is usually explicitly enabled and protected, for example, by a firewall or corresponding configuration of an encrypted connection. Access can be checked or controlled by the local application management system.

[0010] The publication EP 4 007 212 “Method and communication device for monitoring and / or controlling a communication device providing a control application” by Al-Schertler discloses the possibility of transferring applications from one industrial edge device to other industrial edge devices.

[0011] Reference EP 3 537 239 The “Method for Operating a Machine Tool by Adapting a Precompiled Data Model” shows the updating of a machine tool application from a repository in an edge device.

[0012] Finally, EP 3 751 421 A1, "Method for Providing a Control Application and Configuring a Control Device" by Albrecht et al., provides a method and a device for providing an application in a network, wherein a forwarding device is configured with data of a component to be programmed.

[0013] Therefore, there are currently many possibilities for forwarding applications, but they all have fundamental and significant limitations:

[0014] 1. Sales / Distribution via the Marketplace: In this scenario, app developers must go through a costly commercial onboarding process. Furthermore, they cannot distribute their apps through any other means outside of the marketplace. Therefore, commissioned development or test versions cannot be distributed. Sellers cannot refuse individual customers. Furthermore, customer relationships are strengthened with the marketplace provider.

[0015] 2. Use of side channels / sideloading: Application files (files containing applications) are shared between a provider (provider) and a customer (tenant) using file sharing tools (Secufex, Dropbox, email, etc.) or via a USB stick, for example, as packaged Docker containers. The recipient (customer) must then install the application directly on the device to be programmed or load it into a managed "hub" (local application storage) or so-called management system. In the latter case, the hub must be activated for this purpose. This imposes significant security risks, which the recipient along this path bears entirely (network security, compatibility, authenticity, etc.). Furthermore, the sender (provider) cannot verify how, where, and to what extent the transferred application is used, and whether any contractual commitments are adhered to. The provider also faces the risk of widespread infringement of its IP (intellectual property). The use of such side channels exponentially increases the error rate (wrong versions, configuration errors, incompatibilities), while significantly increasing process execution time. Summary of the Invention

[0016] It is therefore an object of the present invention to improve the provision of individual applications (so-called customized applications) in industrial environments by means of software distribution based on an application store.

[0017] This objective is addressed by the feasibility of transferring applications from one hub to other hubs in a controlled manner, more precisely across tenants according to configuration.

[0018] This hub-to-hub transfer (Hub2Hub transfer for short) provides users with complete transparency and cost control, allowing them to deliver their software in just a few clicks. In contrast, unsecured delivery via side channels requires extensive manual work and significantly increases process duration. Furthermore, the use of "sideloading" distribution channels could even be completely blocked in the future, making this currently widely used option obsolete.

[0019] Hub2hub transfer technology enables industrial customers to profitably share their domain knowledge with other organizations in the form of applications, particularly edge applications. Hub2hub transfer is targeted at industrial edge users who wish to distribute specific (test) versions and customized applications ("custom apps") but do not necessarily need to participate in a public marketplace (or app store).

[0020] Therefore, in principle, the following application scenarios can be realized:

[0021] -Customers want to move their own applications back and forth between different lEHub tenants (customer or organizational unit's industrial edge application repository - such as different organizational units or regional country instances).

[0022] - Customers want to co-create with the app provider (joint product design) and quickly access test versions of the app.

[0023] - The provider wants to offer its application only to a certain group of customers because the application is highly adapted ("customized") and has specific domain knowledge.

[0024] This object is achieved in particular by a method according to claim 1 and a device according to claim 10 .

[0025] A method for providing customized applications in an industrial automation component is proposed, each of which has a plurality of automation components. For each industrial automation component, a commercial application is loaded from a public application repository, in particular an application store, and transferred to at least one local application repository. The commercial application is loaded from the local application repository onto the plurality of industrial automation components associated with the local application repository and executed there. The customized application is stored in one of the local application repositories and made available to the automation components associated with the local application repository for download and use. The customized application is transferred from the local application repository to other local application repositories and made available to the automation components associated with the local application repository for download and use. The proposed Hub2Hub transfer method also enables multi-tenant architectures and advanced user rights management for applications that are not distributed via a public marketplace.

[0026] This object is also achieved by an application repository for an industrial automation component, wherein the application repository is designed as a local application repository for loading commercial applications from a public application repository, in particular an application store, and wherein the local application repository is configured to make the loaded application available to at least one automation component belonging to the automation component, in particular for downloading and execution. The local application repository is configured to receive customized applications from a source other than the public application repository, in particular a development system associated with the automation component, wherein the local application repository is configured to transfer at least the customer-specific application to another local application repository, and wherein the local application repository is configured to receive the transferred application from the other local application repository. With this device, the advantages already explained with respect to the method can be achieved.

[0027] According to the present invention, a forwarding message is associated with one or each application. During the transfer from a local application repository to another application repository, compliance with the forwarding message is checked and, if necessary, the transfer is restricted or eliminated accordingly. The forwarding message includes at least one of the following information: whether the transfer is permitted at all, how often the transfer is permitted, how often and / or for how long the corresponding application is permitted to be installed or run on the automation component associated with the target application repository, and / or whether the transfer is permitted to the local application repository of an automation component that is different from the automation component with the local application repository being transferred. This design can apply to both commercial and customer-specific applications. Thus, it is possible for a supplier of the corresponding application to check the forwarding and use of the corresponding application. In particular, it is possible to inseparably associate corresponding instructions or controls with the application for forwarding the application, so that the forwarded application is also subject to the rules. The application repository (central) is advantageously configured to evaluate and implement the corresponding information regarding restrictions and, if necessary, to record and report any forwarding or use of the application to the creator or owner of the application.

[0028] In this context, identity information, in particular a company identity, is advantageously associated with one or each automation component or local application repository or operator (tenant for short). A plurality of permitted identities is defined in the forwarding information, and transfers are only performed to such additional local application repositories (hubs). The same identity information is associated with the additional local application repository or its "tenant," or with an automation component having the same associated identity information, which thus corresponds to one of the permitted identities. This correspondence is checked during application transfer, and the transfer is correspondingly restricted or cleared, if necessary. In the case of a limited number of forwardings, a counter or "account" for the forwarding is decremented with each forwarding. A license for the forwarding can also be obtained, if necessary, so that the required license can be obtained, for example, via an application store.

[0029] Advantageous embodiments of the invention are described in the dependent patent claims. The features and advantages described herein can be realized individually or in suitable combinations. Advantageous embodiments of the method also apply to the device according to the invention, and vice versa.

[0030] Advantageously, at least the application to be transmitted, which is defined in the forwarding information, is signed with a tamper-proof signature, so that unsigned and therefore potentially tampered applications cannot circulate via the Hub2Hub transmission.

[0031] It can be provided that customized applications can only be forwarded between application repositories (hubs) based on the obtained licenses. Furthermore, it can be provided that both application repositories involved must belong to the same tenant or the same tenant group. However, in one embodiment, it can also be provided that commercial applications are provided with a (possibly restricted) forwarding license (or can obtain such a license) according to one of the above methods and are transferred from one local application repository to another. For example, it can be provided that such applications are forwarded only for testing purposes and that time and / or functional restrictions are automatically imposed for this purpose.

[0032] A certain number of licenses for transferring applications can be associated with the local application repository, wherein one of the licenses expires with each transfer and a transfer only occurs if a free license for the transfer exists. The licenses can preferably be obtained from a public application repository (marketplace, app store) or a separate license server (local or global license server). In principle, a number of conditions can be imposed on the licenses, in particular regarding whether only customized applications or commercial applications should be transferred, whether the transfer should be to the local application repository of the own automation component or its own "tenant" or also to the local application repositories of other automation systems (external tenants), and / or regarding the maximum permitted duration or other performance criteria of the application transferred with the corresponding license. Of course, the applications themselves can also be provided with (additional or other) restrictions associated with them.

[0033] In one advantageous variant, each automation component is associated with a local application repository, preferably just one, and applications are supplied from this local application repository, which increases system security. Similarly, each automation component or each tenant is advantageously assigned or added with, preferably just one, own local application repository.

[0034] In a preferred variant, an industrial edge device is used as the target automation component for the application, since such an edge device is well suited for loading software containers that can be managed in their entirety using an application repository.

[0035] If the same protocol used to retrieve commercial applications from public application repositories (marketplaces, app stores) is used for Hub2Hub transmissions, existing application repositories (hubs) can be integrated into the proposed concept with little or no changes. Conversely, for outgoing transmissions, the local application repository can "emulate" the public application repository (marketplace, app store) by using a common protocol relative to the target application repository, thereby reducing or even completely eliminating the need for specific adaptations of the application repository. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] An embodiment of the method according to the present invention is explained below with reference to the accompanying drawings, which simultaneously serve to explain the application repository according to the present invention or the device according to the present invention.

[0037] The single FIGURE shows a schematic diagram of a public network (cloud, internet) with a public application repository and a private industrial area with two automation components and two local application repositories. DETAILED DESCRIPTION

[0038] The accompanying figure shows a typical scenario of an industrial automation environment with two automation components A1 and A2, assuming that they belong to the same company or organizational unit, referred to as "tenant." Automation components A1 and A2 belong to one or more private automation networks, which are connected to a public network CL (cloud; Internet) via devices (gateways, routers, etc.), not shown. A public application repository MP (marketplace, app store) is located in the cloud CL. Automation components A1 and A2, which can be, for example, separate production plants of a manufacturer of industrial products, each have and / or have access to a local application repository H1, H2 (hub); each local application repository can therefore also be run (hosted), for example, in the "cloud." Each local application repository H1, H2 is connected to a local industrial automation component. For clarity, in the accompanying figure, only one industrial edge device (IED) is shown for automation component A2, which is supplied with software via the local application repository H2. The automation components IED have different runtime environments (RE), which, in this exemplary embodiment, are configured to execute applications contained in software containers (so-called Docker containers).

[0039] The engineering system ENG for creating or processing industrial applications is arranged in the automation component A1. However, in other embodiments, the engineering system ENG can also be arranged outside the automation systems A1, A2; for the functions required here, it is only important to provide customized applications.

[0040] Typically, applications are retrieved from a public application repository MP and transferred directly to the device to be programmed (computer, mobile phone, etc.) in the consumer technology sector. However, in the industrial environment described here, commercial applications are first transferred from the public application repository MP to a "local" application repository H1, H2; this is illustrated in the figure by a dotted line between the public application repository MP and the local application repository H1.

[0041] In order to provide or "publish" a customized application provided by the engineering system ENG, the application is transferred to an application repository HI which is local to the engineering system ENG; this is indicated by arrow 1. The local application repository obtains the license LIC required for this purpose at the latest when it is requested to forward the customized application, which is shown in the figure by arrow 2. In the usual scenario, a sufficient number of corresponding licenses are usually stored in advance in the local application repository HI or can be accessed via this local application repository. The license LIC can preferably be obtained or acquired from the public application repository MP; this is indicated by the arrow between the instance MP and the license LIC. Other ways of supplying licenses are also possible. In other cases, for example, individual licenses can also be discarded and permanent licenses can be used instead. It is also possible that the application is provided with a corresponding license and / or is linked to a corresponding license (for example by the engineering system ENG).

[0042] In one possible application scenario, the customized application is not intended to be used in the domain of automation component A1, but rather to be used to program the industrial automation component IED of automation component A2. To this end, a transfer of the application from the local application repository H1 to the local application repository H2 is initiated. Before the transfer, indicated by arrow 3, the local application repository H1 or a component linked thereto, such as a license server, checks whether a corresponding license exists for the transfer and whether any restrictions related to the customized application in question, for example, specified in so-called meta-information, are met for the transfer. The proposed application is then transferred to the local application repository H2, stored there, and made available to the local automation component IED of automation component A2. In the present exemplary embodiment, the proposed application is transferred to the execution environment RE of the automation component IED, as indicated by arrow 4.

[0043] The final steps are carried out in accordance with conventional procedures in the prior art, meaning that additional restrictions or licenses can be set for customized applications, thereby limiting, for example, the number of "deployments," i.e., the number of permitted installations. Other restrictions, such as those related to duration of use, performance, and other criteria, can be specified and enforced via the local application repository H2.

[0044] With this proposed hub2hub transfer method (also known as hub-to-hub), a sophisticated multi-tenant architecture and state-of-the-art user rights management can be provided for applications that are not distributed via official markets (public app stores). Thus, users can provide selected versions of applications to individual recipients (customers and / or tenants) in a fine-grained manner. In this process, it is important that only those applications that have been created internally or have been approved for such transfers can be distributed. This is advantageously achieved by tenant-specific signing of the applications when uploading to the Industrial Edge Hub (IEH), i.e. the local app store. This prevents unnecessary and / or unauthorized transfers (including "purchased" applications, i.e. commercial applications). In this way, a model can be implemented that allows "resale", i.e. the authorized transfer of applications.

[0045] Associativity is ensured by means of different input fields into the user interface of the engineering system or other management components, making it possible to resolve the recipient tenant and also to verify it via the message sent together. By close coordination with the licensing mechanism of the industrial edge device, in addition to the actual application, the number of usage rights (installations or instances on the edge device) can also be transmitted, so that the recipient can also receive the number of licensed installations in addition to the application (application). The recipient is notified about the hub2hub transfer, for example, by email and in the notification menu of the local application database (Industrial Edge Hub). The recipient can now reject or accept the application sent to them based on the information sent at the same time and some metadata. If the recipient accepts, the application will be offered for further installation together with a certain number of licenses sent in the software catalog ("IEH catalog").

[0046] Advantages result with regard to security, anti-counterfeiting, access rights management, and the ability to link applications to automation components, automation parts, and / or tenants.

[0047] Realizable benefits: Save time and money (resources) while improving control, traceability and synchronized version management.

[0048] Technical Features: Easy to use and fully integrated into existing application lifecycle processes. This allows users to build on existing functionality and offer additional applications beyond the hub boundaries. The hub2hub transfer functionality is available to every IEHub customer (Industrial Edge Hub customer) by acquiring the appropriate number of provisioning rights (licenses) through existing channels, such as marketplaces.

Claims

1. A method for providing a customized application in an industrial automation component (A1, A2), each of which has a certain number of automation components (IEDs), in, For each industrial automation component (A1, A2), it is proposed that a checked and certified commercial application is loaded from a public application repository (MP), in particular an application store, and transferred to at least one local application repository (H1, H2). wherein the business application is loaded from the local application repository (H1, H2) onto a number of industrial automation components associated with the local application repository (H1, H2) and executed on the industrial automation components, It is characterized by: receiving, by one of the local application repositories (H1, H2) from a source different from the public application repository (MP), the customized application and providing the customized application to the automation component associated with the local application repository (H1, H2) for download and use, and The customized application is transferred from the local application repository (H1, H2) to another local application repository (H1, H2) and provided to the automation component (IED) associated with the local application repository (H1, H2) for downloading and use, and Forwarding information is associated with one or each application, wherein during a transfer from a local application repository (H1, H2) to another application repository (H1, H2), compliance with the forwarding information is checked and, if applicable, the transfer is accordingly restricted or cleared, wherein the forwarding information comprises at least one of the following information: whether the transfer is permitted at all, how often the transfer is permitted, how often and / or for how long the installation or operation of the corresponding application on an automation component (IED) associated with the target application repository (H1, H2) is permitted, and / or whether the transfer is permitted to a local application repository (H1, A2) of another automation component than the automation component (A1, A2) to which the local application repository (H1, H2) is being transferred. H2)。 2. The method according to claim 1, characterized in that Associating identity information, in particular a company identity, with one or each automation component (A1, A2) or local application repository (H1, H2), wherein a certain number of permitted identities is defined in the forwarding information, wherein a transfer is only permitted to another local application repository (H1, H2) associated with the same identity information or to another local application repository associated with an automation component (A1, A2) having the same associated identity information, wherein the associated identity information corresponds to one of the permitted identities, wherein the correspondence is checked during the transfer of applications and, where appropriate, the transfer is correspondingly restricted or cleared.

3. The method according to claim 2, characterized in that At least the application to be transmitted defined in the forwarding information is signed with a tamper-proof signature.

4. The method according to any one of the preceding claims, characterized in that According to one of the above methods, a business application is equipped with a license for forwarding and is transferred from a local application repository (H1, H2) to another local application repository (H1, H2).

5. The method according to any one of the preceding claims, characterized in that A number of licenses for transferring applications are associated with the local application repository (H1, H2), wherein with each transfer one of the licenses expires, and wherein a transfer is performed only if a free license is available for the transfer.

6. The method according to claim 5, characterized in that In particular, a number of conditions are assigned to the license regarding whether only customized applications or commercial applications can be transferred, whether the transfer can be made to a local application repository (H1, H2) of a user's automation component or to a local application repository (H1, H2) of another automation component (A1, A2), and / or regarding the maximum operating duration of the transferred application.

7. The method according to any one of the preceding claims, characterized in that Each of the automation components (IED) is associated with a local application repository (H1, H2), preferably exactly one local application repository, and retrieves applications from the local application repository.

8. The method according to any one of the preceding claims, characterized in that A local application repository (H1, H2), preferably exactly one local application repository, of the user is associated or added to each automation component (A1, A2).

9. An application repository (H1, H2) for an industrial automation component (A1, A2), wherein: The application repository (H1, H2) is configured as a local application repository (H1, H2), the local application repository is used to load checked and certified commercial applications from a public application repository (MP), in particular an application store or a digital market, The local application repository (H1, H2) is configured to provide the loaded application to at least an automation component (IED) associated with the automation assembly, in particular for downloading and execution. It is characterized by: The local application repository (H1, H2) is configured to receive customized applications from a source different from the public application repository (MP), wherein the further source is in particular a development system associated with the automation component, such that the local application repository (H1, H2) is configured to transfer at least the customized application to the other local application repository (H1, H2), The local application repository (H1, H2) is configured to receive transferred applications from other local application repositories (H1, H2), At least one or each application stored in the local application repository (H1, H2) is provided with forwarding information, which controls the forwarding of the corresponding application to other local application repositories (H1, H2), in particular according to one or more criteria of claim 1 or 2, The transmitting local application repository (H1, H2) is configured to check compliance with the standard during the transmission and to limit the transmission accordingly.

10. The application repository (H1, H2) according to claim 9, characterized in that The local application repository (H1, H2) is linked to a license server, wherein the license server provides at least a portion of the forwarding information about different applications to the local application repository (H1, H2), and wherein the local application repository (H1, H2) is configured to call and check the forwarding information in the context of the transmission of the application.

11. The application repository (H1, H2) according to claim 10, characterized in that The local application repository (H1, H2) is configured to receive at least one license from the license server or from another license server for monitoring the transmission according to any one of claims 6 or 7 and to control the transmission according to conditions of the license.

12. The application repository (H1, H2) according to any one of claims 9 to 11, characterized in that: The local application repository (H1, H2) is configured to supply applications to an industrial edge device as an automation component (IED), wherein the local application repository (H1, H2) is configured to store and transmit applications stored in a container and monitor the installation and operation of the container in the container runtime environment of the edge device.

13. The application repository (H1, H2) according to any one of claims 10 to 14, characterized in that: The local application repositories (H1, H2) are connected to a providing component or are equipped with the providing component, wherein the providing component is configured to provide a first local application repository of the local application repositories (H1, H2) with customized applications, in particular customized applications.

14. The application repository (H1, H2) according to claim 15, characterized in that The providing is performed by means of a protocol of a public application repository (MP), and wherein the local application repository (H1, H2) is configured to receive the application by means of the same protocol.

Images