Method for providing low latency communication between software components of a control system

Abstract

The present invention relates to a method for providing communication between multiple software components in an industrial control system, the method comprising the following steps performed in response to a request from one of the software components to write or read a value of a variable into a common data memory: determining a sub-segment in the common data memory where the variable to be written or read is stored, based on an identifier of the variable to be written or read; determining a memory location of the variable to be written or read, based on an address allocation for the sub-segment; and modifying or reading the variable to be read at the memory location.

Description

Technical Field

[0001] This invention relates to facilitating communication between different software components at different security levels in industrial control systems, particularly in protection and control (P&C) use cases in substations. Background Technology

[0002] The substation is equipped with protection and control (P&C) functions, designed to disconnect the substation from upstream feeders or downstream electrical equipment in the event of abnormal operation. The goal is to isolate any problems before they spread further through the distribution network.

[0003] Previously, P&C functionality running on substation relays followed a monolithic design, allowing only limited configuration based on deployment scenarios and customer needs. However, the current trend is towards virtual relays and on-demand P&C, allowing customers to choose the P&C products and hardware resources they require. This fundamentally necessitates moving away from monolithic designs and towards architectures that support both scaling up and down. Consequently, P&C functionality is now implemented modularly, with multiple communicating software components. Simultaneously, the industry seeks to protect the intellectual property of P&C algorithms, avoiding the disclosure of core algorithms to users. To this end, some software components have been migrated to Trusted Execution Environments (TEEs), where they run in isolation from other software components and the host computing system. This means users can enjoy the benefits of running software components but cannot access their internal mechanisms. Running some software components within a TEE inherently limits communication between them. Summary of the Invention

[0004] Therefore, the objective of this invention is to facilitate low-latency communication between software components of industrial control systems, even when one or more such components are operating under the protection of a TEE.

[0005] This objective is achieved by the method according to the main claim. Further advantageous embodiments are detailed in the dependent claims.

[0006] This invention provides a method for facilitating communication between multiple software components in an industrial control system. The method employs a common data memory to store a set of variables to be communicated. Here, the term "common data memory" should not be construed as meaning that all variables to be communicated must be stored in the same location. Rather, the term simply means that the common data memory as a whole can be treated as an abstract entity that can be invoked to read or write the values ​​of the variables to be communicated. That is, the variables to be communicated can be distributed in one or more memory locations in any suitable manner, but the communication software components do not need to be aware of this distribution detail. Instead, they simply issue requests such as "write this value to variable X" or "read the value of variable Y".

[0007] The common data storage is divided into multiple sub-segments. This is a logical partition, which may correspond to the physical partition, but is not required to. Each variable to be communicated is stored in only one such sub-segment. Each software component is configured to write the value of a variable as output to the common data storage and read the value of a variable from the common data storage as input. The transfer of a value from one software component to one or more other software components is achieved by having the first software component write the value of a variable to the common data storage, and one or more other software components read the value from the common data storage. This is particularly relevant in P&C use cases where many values ​​are written by only a few software components, or even only by one software component, while they are read by many other software components. In other words, a one-to-many allocation of values ​​is prevalent in this use case.

[0008] This method begins when one of the software components requests to write the value of a variable to or read the value of a variable from the common data memory. In response to such a request, the sub-segment in the common data memory where the variable to be written or read is stored is determined based on the identifier of the variable to be written or read.

[0009] Once the sub-segment is known, the memory location of the variable to be written or read can be determined based on its address allocation. Address allocation can take any form, as long as it can produce the memory location of the variable given its identifier. For example, the memory location can be obtained by looking up a table, and / or it can be calculated at least partially based on the identifier. Each sub-segment can sample an independent address allocation method, meaning different sub-segments may allocate addresses in different ways.

[0010] Once the memory location is known, the variable to be written can be modified at that memory location, or the variable to be read can be retrieved from that memory location.

[0011] On the surface, using a shared data memory divided into multiple sub-segments seems to add unnecessary complexity, contradicting the goal of achieving low-latency communication between software components. However, this is not the case. On the contrary, this partitioning offers a dual advantage in terms of latency:

[0012] First, it reduces dependencies between variables and decreases contention when accessing multiple variables. Multiple software components execute concurrently. This means that at any given time, a large number of variables are being read from and written to a shared data store. Dividing the shared data store into multiple sub-segments significantly reduces the likelihood of a software application having to wait for other software applications due to contention for access to required variables. This, in turn, reduces expected latency.

[0013] Secondly, determining the memory address of a variable by first identifying the sub-segment where it is stored and then using the address allocation of that sub-segment is likely more efficient than determining the memory address from a single address allocation across the entire shared data store. For example, if a table is used to look up a memory address based on the variable's identifier, the identifier must be compared one by one with the identifiers in every row of the table until a match is found, at which point the corresponding memory address in that row can be used. The workload required for this increases linearly with the number of variables to be communicated. By directly jumping to a smaller lookup table containing the known sub-segments where the variables are stored, computational overhead can be significantly reduced.

[0014] In a particularly advantageous embodiment, the multiple software components have different security levels. This may require isolating the software components from each other by running them in different execution environments (e.g., virtual machines or secure zones). This isolation, in turn, limits the possibility of direct communication between the software components, thus creating a need to use a shared data storage as a communication medium.

[0015] Therefore, specifically, the multiple sub-segments can be located in one or more physical locations with potentially different security levels. This means that the physical locations can be isolated from each other through security measures. For example, each physical location can belong to a different execution environment, and other execution environments may be prohibited from accessing memory belonging to a particular execution environment.

[0016] In another particularly advantageous embodiment, each variable to be communicated is stored in only one sub-segment of the common data memory. In this way, whenever this variable needs to be updated, only one location in the common data memory is affected.

[0017] The optimal way to specifically divide all communicateable variables into multiple sub-segments depends on the specific use case. Choosing a reasonable division is particularly beneficial in avoiding the aforementioned race conditions. In a particularly advantageous embodiment, at least one sub-segment contains only the communicateable variables that are to be written by the same software component during the expected operation of the control system. That is, the communicateable variables can be grouped into sub-segments by the software component that will write them: the first group can contain all variables to be written by software component A and only by software component A, the second group can contain all variables to be written by software component B and only by software component B, and so on. This means that, for example, whenever a software component is about to write the value of one or more variables to a common data storage, it can lock only the sub-segment containing the variables to be written by that software component. All other variables are unaffected by the expected write operation and can continue to be used by other software components without hindrance.

[0018] Isolating communication variables, especially those written to by the software components, has the added benefit of limiting potential communication paths between different software components. In other words, communication via a shared data store can be configured to occur only along planned paths between software components. This makes it more difficult to intentionally disrupt a software application's behavior by injecting communication from entirely unexpected sources.

[0019] In another particularly advantageous embodiment, the sub-segment in the public data storage where the variable to be written or read is stored is determined based on a table that assigns a sub-segment of the public data storage for each identifier of the variable to be communicated. For example, the table can operate based on portions of the identifier, thus determining the sub-segment is still much faster than looking up the complete identifier in the table. In a simple example, the first digit of the variable's numeric identifier can be used to determine the sub-segment of the public data storage where the variable is stored.

[0020] In another particularly advantageous embodiment, the address allocation of at least one sub-segment is based, at least in part, on the hash value or other compressed digest of the identifier of the variable to be written or read. Specifically, such a hash value or other compressed digest can be used directly, or after a small amount of additional computation (such as adding an offset), as the memory address of the sought variable to be written or read. That is, the sub-segment can act as a kind of key-value hash mapping, where the hash of the key (here: the identifier) ​​is used to determine the location of the variable value in memory. The advantage of this is that the time required to compute the hash value or other compressed digest to determine the sought memory location remains constant, regardless of how many variables the corresponding sub-segment contains. The hash value or other compressed digest does not need to be cryptographically secure, i.e., given a hash value, it is difficult to deliberately generate another input that maps to the same hash value. The probability that two or more variables are assigned the same hash value or other compressed digest and thus the same memory location remains negligible.

[0021] In another particularly advantageous embodiment, a write lock or read lock is acquired for the variable to be written or read and / or the memory location where the variable is stored, respectively, before modifying the variable to be written or read and before reading the variable to be read. The write lock or read lock is released after modifying the variable to be written or after reading the variable to be read. In this way, it is prevented that a software component reads a value while another software component is modifying that value. This situation could lead to the reading software component using an incorrect variable value. Specifically, the write lock can be exclusive, i.e., only a single write lock is allowed for a given resource (e.g., a variable or memory location), and other software components cannot acquire a read lock while that write lock is active. On the other hand, the read lock can be shared, i.e., multiple read locks can exist simultaneously for the same resource. The presence of a read lock only prevents the acquisition of a write lock.

[0022] In addition to locking mechanisms, other concurrency mechanisms for concurrent access to variables can be used, such as multi-versioning or any other type of lock-free concurrency.

[0023] Specifically, write locks or read locks can be acquired separately for each sub-segment containing the variable to be written or read in the common data memory. In most applications, this mechanism achieves a good balance between locking the entire common data memory and performing extremely fine-grained lock management for each individual variable to be communicated. As mentioned earlier, appropriately dividing the variable to be communicated into sub-segments can minimize the impact of locking on the operation of other software components.

[0024] In another particularly advantageous embodiment, when multiple variables need to be written to and / or read in a single computational transaction, all necessary write locks and / or read locks are acquired uniformly before computation begins and released uniformly after computation is completed. This ensures that the entire transaction completes smoothly and is not stalled due to the unavailability of required resources (i.e., variables).

[0025] This real-time transaction support is particularly important for protection and control (P&C) functions in substations. This implies deterministic, extremely low latency (microseconds) and atomic execution of batch operations within a single transaction. Using a traditional database as the communication medium between software components requires no prior knowledge of the properties of the variables being communicated, as databases are general-purpose tools. However, this comes at the cost of relatively slow database performance. In particular, real-time transaction support is difficult to achieve due to the significant uncertainty involved from aborts and retries. This makes achieving both real-time latency and determinism extremely challenging. In contrast, the method proposed in this paper leverages prior knowledge about the software components involved and their behavior, thereby improving performance in this specific application.

[0026] In another particularly advantageous embodiment, multiple write locks and / or read locks are acquired sequentially according to the ordered hierarchy of the affected variables and / or sub-segments. These multiple write locks and / or read locks are then released in the reverse order of acquisition. In this way, when two or more software components compete for locks on a specific set of resources, there is always a winner. This means that deadlocks can be avoided: each software component waiting for another software component to release its lock on a resource. For example, sub-segments might be in a linear hierarchy of 1, 2, 3, ... If there are requests for sub-segments 4, 6, and 2, the locking order is: first acquire the lock on sub-segment 2, then acquire the lock on sub-segment 4, and finally acquire the lock on sub-segment 6. It is particularly important to note that the locking action may employ a blocking call mechanism, meaning that higher-numbered sub-segments cannot be locked until locks on all lower-numbered sub-segments have been acquired.

[0027] In traditional databases, each write operation is random, thus requiring the locking of a large portion of the database at any given time. The method proposed in this paper significantly reduces the proportion of variables awaiting communication that are locked at any given moment. For example, if variables awaiting communication are grouped into sub-segments based on the entities to which they are to be written, only that specific sub-segment needs to be locked when it is the entity's turn to be written.

[0028] In another particularly advantageous embodiment, different sub-segments of the public data storage reside in memory regions with different security protection levels. This allows sensitive data to be protected on demand without requiring the read / write software components to concern themselves with security details. All of this is handled by the abstraction layer introduced by this method. For example, a "secure data storage" can be set up containing only those sub-segments to be exchanged between specific software components deemed secure; there can also be a "general data storage" containing those sub-segments to be exchanged between "secure" software components and other software components. Furthermore, or in combination with the above schemes, variables to be communicated can be marked as "public" to allow free exchange between software components, or marked as "private" to be allocated arbitrarily only within a restricted subset of software components.

[0029] Typically, software components execute on a host computing system. For example, for each software component, a container, virtual machine, or other execution environment can be set up under the control of the operating system running on the host computing system. In one example, at least one sub-segment of a common data store resides in the regular random access memory (RAM) of the host computing system on which the system controls the operation. Simultaneously, at least one sub-segment of the common data store resides in a Trusted Execution Environment (TEE), within which at least a portion of the system's software components run in isolation from the host computing system and the operating system running on it. This prevents unauthorized access to sensitive variables. Sensitive variables owned by software components running in the TEE can be shared with other software components, but through the abstraction layer introduced by this approach, access permissions are strictly limited to those other software components that are actually planned and desired to have access.

[0030] In another particularly advantageous embodiment, the division of the common data storage into sub-segments is determined based on the control system's configuration information at startup. In this way, the configuration of the common data storage can be adapted to the specific needs of the control system's configuration. For example, having a modular control system means that a particular module may exist in one specific control system but not in another.

[0031] For example, in the P&C functionality use case for substations, a customer can request a specific list of P&C functions from a range of products offered by one or more vendors to manage their assets (e.g., substations). A configuration file can then be generated, specifically including the following:

[0032] • Various functions (products) requested by the customer are configured to run in independent software components. Each software component must contain at least one function; and

[0033] • For each software component, the dataset (signals) used by this function is the input and output set of that software block. Therefore, the data for the entire system will include all signals that are input to all components and all signals that are output from all components.

[0034] From this configuration file, data exchanged between different components can be extracted. This data constitutes the variables to be communicated, which will be stored in a common data store, i.e., the communication medium used in the context of this method.

[0035] As the first step in the extraction mechanism, the configuration file can be examined to extract the read and write sets for each software component. For a specific component, its read set is the collection of all data (signals) input to all functions of that component, and its write set is the collection of all data (signals) output from all functions of that component. This extraction can be achieved, for example, by implementing appropriate parsing techniques for the configuration file.

[0036] Furthermore, signals in the read and write sets can be tagged to reflect how they are used. An example of such tagging is assigning "private" and "public" labels to signals, where private data signals are exchanged between a pair of "secure" software components, while public data signals are shared between all other software component pairs.

[0037] To reduce dependencies between various software components implementing different P&C functions, a data store can be dynamically constructed based on the required customer configuration. Specifically, the data store can be constructed as a collection of multiple hash maps, with each software component corresponding to at most one hash map in the configuration. However, this internal structure of the data store is not visible to the software components, but is abstracted through an interface to provide the illusion of a single data structure. Which data resides in which hash map within the semaphore store is determined based on the proposed method during debugging or system startup and remains static for a given execution configuration.

[0038] For each sub-segment, the hash map can then store the data in the form of <key, value>, where the key is the name of the data (signal) and the value is the numerical value of that specific signal. The set of keys stored in the hash map can be calculated, for example, by determining the overlapping area between the write set of a software component and the read sets of all other software components.

[0039] In addition to hash mapping, a circular buffer can also be used to transmit large and constantly changing signal streams.

[0040] As mentioned earlier, variables to be communicated can be tagged with assignment labels to indicate which software components they should be shared among. This helps to optimally group them into sub-segments, thereby reducing contention and preventing communication along unintended paths.

[0041] As previously mentioned, in a particularly advantageous embodiment, the control system may be selected to implement at least one protection and control (P&C) function for power distribution within the substation. As noted above, this use case places extremely stringent requirements on low latency. In particular, if a substation detects a problem on an upstream feeder or downstream user, action must be taken within microseconds. Failure to act promptly and isolate the fault will result in the substation itself being isolated as a source of fault by other substations. Furthermore, the actions to be taken often involve tasks that must be completed from start to finish. For example, when rerouting power through another part of the substation, several switches may have to be opened and closed in a precise sequence to ensure, for example, that disconnecting switches do not disconnect under full load and suffer arcing damage.

[0042] Therefore, in another particularly advantageous embodiment, the P&C function includes disconnecting at least one feeder to the substation and / or at least one electrical output from the substation in response to determining that the current, voltage, load, or frequency of the electrical energy to be distributed deviates from its respective acceptable range.

[0043] In another particularly advantageous embodiment, in response to the completion of writing at least one value of a variable to a common data memory and / or reading at least one value of a variable from the common data memory, the industrial control system causes a change in the physical behavior of the industrial plant or facility controlled by the industrial control system. Specifically, this can be achieved by actuating an actuator of the industrial control system, which influences the physical behavior of the industrial plant or facility through actuation signals from one or more software components of the industrial control system. In this way, the improved low-latency communication between the software components of the industrial control system has a beneficial effect: the physical behavior of the industrial plant or facility is more consistent with its operating condition. This is because low-latency communication enables the industrial control system to react more quickly to any changes in operating condition. This is especially true when at least one variable to be communicated is a measurement acquired using at least one sensor of the industrial plant or facility. In particular, the operating condition of the industrial plant or facility can be characterized by multiple such measurements.

[0044] Because it is implemented by a computer, this method can be embodied in software. Therefore, this invention also relates to a computer program containing machine-readable instructions that, when executed by one or more computers and / or computing instances, cause said one or more computers and / or computing instances to perform the above-described method. Examples of computing instances include virtual machines, containers, or serverless execution environments in the cloud. This invention also relates to a machine-readable data carrier and / or downloadable product containing the computer program. A downloadable product is a digital product containing the computer program that can be sold, for example, in an online store for immediate fulfillment and download to one or more computers. This invention also relates to one or more computing instances containing the computer program, and / or the machine-readable data carrier and / or downloadable product. Attached Figure Description

[0045] The invention is described below with reference to the accompanying drawings, which are not intended to limit the scope of the invention. The drawings show:

[0046] Figure 1 An exemplary embodiment of a method 100 for providing communication among multiple software components of an industrial control system is shown;

[0047] Figure 2 An exemplary implementation of a public data storage 3 for sharing data among multiple software applications 2a-2d is shown;

[0048] Figure 3 Examples are shown where different sub-segments of a common data storage are located in memory regions with different protection levels. Detailed Implementation

[0049] Figure 1 This is a schematic flowchart of an embodiment of a method 100 for providing communication between multiple software components 2a-2d of an industrial control system 1. The industrial control system 1 controls an industrial plant or facility 5, such as a substation.

[0050] like Figure 2 and Figure 3 As will be described in further detail, communication between multiple software components 2a-2d utilizes a common data memory 3, which stores a set of variables 4 to be communicated. The common data memory 3 is divided into multiple sub-segments 3a-3c. Each variable 4 to be communicated is stored in only one such sub-segment 3a-3c.

[0051] According to box 105, the process of dividing the common data storage 3 into sub-segments 3a-3c can be determined based on the configuration information 1a of the control system 1 when the control system 1 is started.

[0052] According to block 106, the control system 1 may be selected to implement at least one protection and control (P&C) function for power distribution in the substation. Specifically, according to block 106a, the P&C function may include disconnecting at least one feeder to the substation and / or at least one electrical output from the substation in response to determining that the current, voltage, load, or frequency of the power to be distributed deviates from its respective acceptable range.

[0053] This method begins when one of the software components 2a-2d requests to write the value of variable 4 to or read the value of variable 4 from the common data memory 3. This occurs repeatedly during the operation of the industrial control system 1. This means that the method will be executed repeatedly, and concurrently for multiple variables 4 at any given time.

[0054] In step 110, based on the identifier of the variable 4 to be written or read, the sub-segments 3a-3c in the public data storage 3 where the variable 4 to be written or read is stored are determined.

[0055] According to box 111, at least one sub-segment 3a-3c may contain only the communication variables 4 to be written by the same software components 2a-2d in the intended operation of the control system 1. That is, the communication variables 4 may be grouped by the software components 2a-2d responsible for writing them.

[0056] According to box 112, the sub-segments 3a-3c in the common data storage 3 where the variable 4 to be written or read is stored can be determined from a table that allocates a sub-segment 3a-3c of the common data storage 3 for each identifier of the variable 4 to be communicated.

[0057] According to box 113, different sub-segments 3a-3c of the common data storage 3 can be located in memory regions with different security protection levels. In particular,

[0058] • According to block 113a, at least one sub-segment 3a-3c of the common data memory 3 may be located in the conventional random access memory (RAM) 6 of the host computing system 7 on which the control system 1 operates; and

[0059] • According to box 113b, at least one sub-segment 3a-3c of the public data storage may be located in a Trusted Execution Environment (TEE) 8a-8c, in which at least a portion of the software components 2a-2d of the control system 1 runs in isolation from the host computing system and the operating system running on the host computing system 7.

[0060] This will Figure 3 Further details are provided in the link.

[0061] In step 120, based on the address allocation 3a#-3c# of the sub-segment 3a-3c, the memory location 4a of the variable 4 to be written or read is determined.

[0062] According to box 121, the address assignment 3a#-3c# of at least one sub-segment 3a-3c can be based at least in part on the hash value or other compressed digest of the identifier of the variable 4 to be written or read.

[0063] exist Figure 1 In the example shown, in step 130, a write lock or a read lock is acquired for the variable 4 to be written or read and / or the memory location 4a where the variable 4 is stored. However, as mentioned earlier, contention for concurrent access to the same variable 4 can also be managed in a lock-free manner.

[0064] According to box 131, write locks or read locks can be acquired for the sub-segments 3a-3c of the public data storage 3, where the variables to be written or read 4 are stored.

[0065] According to box 132, in the case of writing and / or reading multiple variables 4 in a single computational transaction, all necessary write locks and / or read locks can be acquired before the computation begins (132).

[0066] Specifically, according to box 132a, multiple write locks and / or read locks can be acquired sequentially based on the ordered hierarchical structure of the affected variable 4 and / or sub-segments 3a-3c.

[0067] If the request is a write request, then in step 140a, the variable 4 to be written is modified at the determined memory location 4a. Similarly, if the request is a read request, then in step 140b, the variable 4 to be read is read from the determined memory location 4a.

[0068] exist Figure 1 In the example shown that uses a locking mechanism to manage contention, in step 150, the acquired write lock or read lock is released.

[0069] According to box 151, in the case of writing and / or reading multiple variables 4 in a single computational transaction, all necessary and previously acquired write locks and / or read locks can be released after the computation is completed.

[0070] Specifically, according to box 151a, multiple write locks and / or read locks can be rereleased in the reverse order of acquisition.

[0071] exist Figure 1 In the example shown, in step 160, in response to the completion of writing at least one value of variable 4 to common data memory 3 and / or reading at least one value of variable 4 from common data memory, industrial control system 1 causes a change in the physical behavior of industrial plant or facility 5 controlled by industrial control system 1.

[0072] Figure 2 An example illustrates how to implement a common data storage 3 for sharing data among multiple software components 2a-2d. Figure 2 In the example shown, the industrial control system 1 is implemented on the host computing system 7 and includes four software components 2a-2d. Software component 2a runs in a VM-based protected execution environment (e.g., AMD SEV or Intel TDX), taking inputs labeled "In 1" and producing outputs labeled "Out 1". Software component 2b runs in another VM-based protected execution environment, taking inputs labeled "In 2" and producing outputs labeled "Out 2". Software component 2c runs in an application-based protected execution environment (e.g., Intel SGX), taking inputs labeled "In 3" and producing outputs labeled "Out 3". Software component 2d is a non-secure component that runs directly on the operating system of the host computing system 7 without any special protection.

[0073] All software components 2a-2d exchange variables 4 with a common data memory 3 located in the non-secure random access memory (RAM) of the host computing system 7. The common data memory 3 has multiple sub-segments 3a-3c. According to block 111 of method 100 described above, each sub-segment 3a-3c is configured to receive the output ("Out 1", "Out 2", ..., "Out n") of exactly one software component 2a-2d, which will be read as input ("In 1", "In 2", ..., "In n") by the corresponding other software components 2a-2d. In this way, when a software component 2a-2d wants to write, it only needs to lock the corresponding sub-segment 3a-3c of the common data memory 3.

[0074] Figure 3 An example illustrates how public data storage 3 can be partitioned between memory regions with different security protections.

[0075] exist Figure 3 In the example shown, software components 2a-2d and Figure 2 The same as in [the previous text]. Furthermore, software components 2a-2c are in [the same context]. Figure 2 They run in the same trusted execution environments 8a-8c. However, the diagram shows in detail software component 2a running in virtual machine execution environment 8a. This software component 2a includes:

[0076] Virtual P&C Platform 91;

[0077] · Multiple containers hosting non-real-time services (92);

[0078] • P&C module 93 with a runtime of 1 millisecond;

[0079] • A custom module with a runtime of 10 milliseconds (94);

[0080] • The GOOSE application is used to process events according to the IEC 61850 standard in substations within industrial plants or facilities 5; and

[0081] • A protocol / API frontend 96.

[0082] The virtual P&C platform 91 includes other optional runtimes 91a and 91b to extend the platform, as well as a monitor 91c.

[0083] exist Figure 3 In the example shown, the common data storage 3 is divided into three sub-segments 3a-3c, namely:

[0084] • The first sub-segment 3a contains the communication variables 4 that are read and written only by the security software components (2a-2c in this case);

[0085] • The second sub-segment 3b contains the communication variable 4, which is written only by the security software components (2a-2c in this case) but can be freely read by all software components 2a-2d; and

[0086] • The third sub-segment 3c contains communication variables 4 that can be freely written by non-secure third-party software components and can be freely read by all software components 2a-2d.

[0087] The second sub-segment 3b and the third sub-segment 3c reside in the regular RAM of the host computing platform 7. However, the first sub-segment 3a, which is the portion that even insecure software components (here: 2d) are not allowed to read, resides in a virtual P&C platform 91 within a virtual machine-based trusted execution environment 8a. Within this trusted execution environment 8a, there are mount points 3b' and 3c' through which the second sub-segment 3b and the third sub-segment 3c can be accessed without considering that these sub-segments 3b and 3c reside in completely different memory domains.

[0088] List of reference numerals in the attached diagram:

[0089] 1 Industrial Control Systems

[0090] Software components of 2a-2d industrial control systems

[0091] 3. Common data storage for variables to be communicated 4

[0092] 3a-3c Subsegment of common data memory 3

[0093] Address allocation for sub-segments 3a#-3c#

[0094] Mount points of subsegments 3b and 3c in execution environment 8a, 3b' and 3c'.

[0095] 4 Variables to be communicated

[0096] 4a Memory location of variable 4 to be communicated

[0097] 5. Industrial plants or facilities controlled by industrial control system 1

[0098] Random Access Memory (RAM) of the 6 mainframe computing platform 7

[0099] 7. Host computing platform running industrial control system 1

[0100] Secure (Trusted) Execution Environment on 8a-8c Mainframe Computing Platform 7

[0101] Virtual P&C Platform in Software Component 2a (91)

[0102] The first optional runtime of Virtual P&C Platform 91 in Software Component 2a of 91a.

[0103] The second optional runtime in the Virtual P&C Platform 91 of Software Component 2a (91b).

[0104] Containers with non-real-time services in Software Component 2a (92)

[0105] The P&C module in Software Component 2a of 93

[0106] Custom modules in Software Component 2a (94)

[0107] GOOSE application in Software Component 2a of 95

[0108] Protocol / API Frontend in Software Component 2a (96)

[0109] 100 provides a method for communication between software components 2a-2d.

[0110] 105. When the industrial control system 1 starts up, determine sub-segments 3a-3c.

[0111] 106. Select an industrial control system to implement the P&C function of a substation.

[0112] Specific details of 106aP&C functionality

[0113] 110. Determine the sub-segment 3a-3c where variable 4 is stored to be read / written.

[0114] 111 Grouping of variable 4 by writing to software components 2a-2c

[0115] 112. Determine sub-segments 3a-3c based on the table.

[0116] 113 Store sub-segments 3a-3c into memory with different security protection levels.

[0117] 113a places sub-segments 3a-3c into regular RAM.

[0118] 113b places subsections 3a-3c in trusted execution environments 8a-8c.

[0119] 120 Determine the memory location of variable 4a to be read / written.

[0120] 121 Use hashing or other compression products for address allocation 3a#-3c#

[0121] 130 Acquires the lock for variable 4 / memory location 4a

[0122] 131. Acquire the lock for sub-segment 3a-3c stored in variable 4.

[0123] 132 Acquire all necessary locks before starting to compute the transaction.

[0124] 132a Acquiring locks by ordered hierarchy

[0125] 140a Modify variable 4 to be written

[0126] 140b Read the variable to be read 4

[0127] 150 Release the previously acquired lock

[0128] 151. Release the lock after the transaction is completed.

[0129] 151a releases the lock in the reverse order of acquisition.

[0130] 160 triggers physical actions in industrial plants or facilities 5.

Claims

1. A method (100) for providing communication between multiple software components (2a-2d) in an industrial control system (1) using a common data storage (3), wherein the common data storage stores a set of variables to be communicated (4), wherein The common data storage (3) is divided into multiple sub-segments (3a-3c). Each variable to be communicated (4) is stored in at least one of its sub-segments (3a-3c), and Each software component (2a-2d) is configured to write the value of variable (4) as output to the common data memory (3) and read the value of variable (4) as input from the common data memory (3). The method (100) includes the following steps performed in response to a request from one of the software components (2a-2d) to write the value of variable (4) to the public data storage (3) or to read the value of variable (4) from the public data storage (3): Based on the identifier of the variable to be written or read (4), determine the sub-segment (3a-3c) where the variable to be written or read (4) is stored in the public data storage (3) (110). Based on the address allocation (3a#-3c#) of the sub-segment (3a-3c), determine the memory location (4a) of the variable (4) to be written or read (120); and Modify (140a) the variable (4) to be written at memory location (4a), or read (140b) the variable (4) to be read from memory location (4a).

2. The method (100) according to claim 1, wherein the plurality of software components (2a-2d) have different security levels.

3. The method (100) according to any one of claims 1 to 2, wherein the plurality of sub-segments (3a-3c) are located in one or more physical locations with different security levels.

4. The method (100) according to any one of claims 1 to 3, wherein each variable to be communicated (4) is stored in only one of the sub-segments (3a-3c).

5. The method (100) according to any one of claims 1 to 4, wherein at least one sub-segment (3a-3c) contains only (111) the communication variables (4) to be written by the same software component (2a-2d) in the intended operation of the control system (1).

6. The method (100) according to any one of claims 1 to 5, wherein the sub-segments (3a-3c) in which the variables (4) to be written or read are stored in the public data storage (3) are determined from a table (112) that assigns a sub-segment (3a-3c) of the public data storage (3) to each identifier of the variable (4) to be communicated.

7. The method (100) according to any one of claims 1 to 6, wherein the address allocation (3a#-3c#) of at least one sub-segment (3a-3c) is based at least in part on the hash value or other compressed digest of the identifier of the variable (4) to be written or read (121).

8. The method (100) according to any one of claims 1 to 7, further comprising: Before modifying (140a) the variable to be written (4) or before reading (140b) the variable to be read (4): acquire (130) a write lock or a read lock for the variable to be written or read (4) and / or the memory location (4a) where the variable to be written or read (4) is stored; as well as After modifying (140a) the variable to be written (4), or after reading (140b) the variable to be read (4): release the write lock or read lock as described in (150).

9. The method (100) according to claim 8, wherein the write lock or read lock is acquired (131) for the sub-segment (3a-3c) where the variable to be written or the variable to be read (4) is stored in the public data memory (3).

10. The method (100) according to claim 8 or 9, wherein, In the case of writing and / or reading multiple variables in a single computational transaction (4), all necessary write locks and / or read locks are acquired before the computation begins (132) and released again after the computation is completed (151).

11. The method (100) according to claim 10, wherein The multiple write locks and / or read locks are acquired in order according to the ordered hierarchical structure based on the affected variables (4) and / or sub-segments (3a-3c) (132a); and The plurality of write locks and / or read locks are released again in the reverse order of the order in which they were acquired (151a).

12. The method (100) according to any one of claims 1 to 11, wherein the different sub-segments (3a-3c) of the common data storage (3) are located in memory regions (113) with different security protection levels.

13. The method (100) according to claim 12, wherein At least one sub-segment (3a-3c) of the common data storage (3) is located in the conventional random access memory (RAM) (6) of the host computing system (7) on which the control system (1) runs (113a); and At least one sub-segment (3a-3c) of the public data storage is located in a Trusted Execution Environment (TEE) (8a-8c) (113b), in which at least a portion of at least one software component (2a-2d) of the control system (1) operates in isolation from the host computing system and the operating system running on the host computing system (7).

14. The method (100) according to any one of claims 1 to 13, wherein dividing the common data storage (3) into sub-segments (3a-3c) is determined (105) based on the configuration information (1a) of the control system (1) when the control system (1) is started.

15. The method (100) according to any one of claims 1 to 14, wherein the variable to be communicated (4) is tagged with an assignment label indicating which software components (2a-2d) the variable is expected to be shared.

16. The method (100) according to any one of claims 1 to 15, wherein the control system (1) is selected (106) to implement at least one protection and control P&C function in a substation for power distribution.

17. The method (100) of claim 16, wherein the protection and control P&C function includes (106a) disconnecting at least one feeder to the substation and / or at least one electrical output from the substation in response to determining that the current, voltage, load or frequency of the electrical energy to be distributed deviates from its respective acceptable range.

18. The method (100) according to any one of claims 1 to 17, further comprising: In response to writing at least one value of variable (4) into the common data storage (3) and / or reading at least one value of variable (4) from the common data storage, the industrial control system (1) causes (160) a change in the physical behavior of the industrial plant or facility (5) controlled by the industrial control system (1).

19. A computer program comprising machine-readable instructions that, when executed by one or more computers and / or computing instances, cause the one or more computers and / or computing instances to perform the method (100) according to any one of claims 1 to 18.

20. A non-transitory machine-readable data carrier and / or downloadable product comprising the computer program according to claim 19.

21. One or more computers and / or computing instances comprising the computer program of claim 19, and / or the non-transitory machine-readable data carrier and / or download product of claim 20.

Images