Systems and methods for modeling and assessing risk

Abstract

The present disclosure relates to systems and methods for modeling and assessing risk. Disclosed are a system, method, and non-transitory computer-readable medium for modeling the risk of a system under assessment (SUA) and automatically assessing its security and / or confidentiality compliance. The present disclosure is particularly applicable to standalone assessments of SUAs and does not constitute a part of a SUA.

Description

Technical Field

[0001] The present disclosure relates to systems and methods for modeling and assessing risk. Background Art

[0002] The following discussion of the background art is intended only to facilitate understanding of the present disclosure. It should be appreciated that the discussion is not an acknowledgement or admission that any of the material referred to was published, known or part of the common general knowledge of the skilled person in any jurisdiction before the priority date of the present invention.

[0003] Risk modeling and assessment are essential activities throughout the lifecycle of a component, device, or system. One approach involves manually documenting potential hazards and possible mitigations for those hazards. While documentation can be supported using tools such as spreadsheets, these tools are typically designed for managing documents and cannot be used to perform deep semantic analysis or automate decision-making processes. Furthermore, manual documentation of risk identification can be labor-intensive, which can lead to increased costs, reduced efficiency, or human error.

[0004] In addition to the manual approaches mentioned, various approaches to modeling and assessing risk have been considered, such as model-based engineering. Generally speaking, such model-based engineering approaches aim to provide notations and tools for modeling functional and safety-related characteristics within an overall system design, integrated design, and risk assessment. This connection between the "design system" and the "assessed system" is particularly problematic for independent review. Furthermore, integration unnecessarily limits risk assessment and evaluation to the elements included in the model. Consequently, any protective measures that exist in the environment but are not part of the system design will be missed. Furthermore, model-based engineering approaches cannot analyze system-of-systems (STSs) of dynamic or autonomously interacting systems. Furthermore, engineering approaches often require that all suppliers design their components using the same methodology, a potentially unrealistic assumption.

[0005] Another approach, summarized as "runtime methods", proposes various ways to estimate the risk of the assessed system at runtime and change the system behavior accordingly. It should be recognized that such methods do not evaluate protective measures but implement them.

[0006] Another approach, generally referred to as "formal methods," relies on formal modeling of the underlying system. However, such models are often difficult to use because risk assessors may not be well-versed in formal modeling. Furthermore, due to the computational complexity associated with formal modeling, known formal models can be limited in their application and involve the use of intensive computing resources. Existing formal methods may not satisfactorily handle the dynamic changes and interacting elements within the assessed system.

[0007] In summary, existing systems and methods have significant shortcomings in modeling and assessing risk. Depending on the method used, they are not completely independent of the assessed system, cannot achieve complete risk modeling, and are often domain-specific.

[0008] What is needed is an improved system and method to alleviate one or more of the above-mentioned problems. Summary of the Invention

[0009] The present disclosure provides a system capable of automatically assessing the security and / or privacy compliance of interacting industrial assets in an adaptive or dynamic manner.

[0010] It addresses the security and / or confidentiality challenges posed by the Industry 4.0 paradigm, namely increased interconnectivity, flexibility and adaptability to change, with the goal of maximizing asset efficiency and value generation.

[0011] The system features a method for modeling security and confidentiality risks to industrial assets as defined in existing standards. In the area of personal safety, risks may be associated with harm in the form of bodily injury or other consequences to the health of living things (such as humans). The method can also model and assess security risks associated with physical damage to property and / or the environment. Overall, it enables the assessment of application-specific security and confidentiality risks arising from the interaction of any pair of assets. The present disclosure is applicable to increasing the speed and flexibility of risk assessment in a manner that reduces human error. The system and method can be deployed in a variety of operational use cases.

[0012] The system can be integrated with traditional safety and / or security assessment workflows. It can also form part of development activities for the design and manufacture of components, products and subsystems in the context of the Industrial Internet of Things (IIoT).

[0013] The system can also be used for future standardization efforts. It should be appreciated that the system and method provide a formalism that is easy for subject matter experts to understand but still formally correct. It overcomes challenges that can exist for both humans and machines.

[0014] The system can be deployed with already validated system applications in terms of safety and / or security to dynamically reassess compliance when certain characteristics or parameters within the system under assessment (SUA) change.

[0015] The system models one or more risks (hazards / threats) based on a mapping of natural language to machine-interpretable semantics based on SUA's functional and operational adjustments. This mapping formalizes risk assessment (which may include risk analysis, risk estimation, and risk evaluation) in a machine-readable language to allow adaptive risk assessment, risk reduction, and ideally, automated security certification.

[0016] System semantics can be formally defined as the risk model associated with a SUA. Each level in the risk model's abstract hierarchy can be reduced to lower-level constructs, providing precise semantic meaning. At the lowest level, hazard modeling, as well as risk assessment and mitigation according to the present disclosure, is based on the mathematical rigor of set theory, type theory, and structure.

[0017] Other aspects and features of the present disclosure are described in the following description of specific embodiments in conjunction with the accompanying drawings. Those skilled in the art will recognize and understand that the embodiments are non-limiting examples. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In the drawings, which illustrate embodiments of the present invention by way of example only,

[0019] Figure 1 A conceptual overview of the relationship between the risk modeling and assessment system of the present disclosure and the assessed system is shown.

[0020] Figure 2 is a system diagram of a risk modeling and assessment system according to an embodiment.

[0021] Figure 3a 、 3b , 3c and 3d illustrate possible structures of an electronic model specification 120 for use with a risk modeling and assessment system. Figure 3a The syntax of the electronic model specification 120 in XML format is shown in FIG. Figure 3b Lists the top-level elements of a modeling language, Figure 3c Lists the basic language elements of the modeling language, and Figure 3d Lists the basic types of the type system.

[0022] Figure 4 Components of an extensible application programming interface (API) that may be used for implementation of risk modeling and risk assessment according to some embodiments are shown.

[0023] Figure 5 An embodiment of a modeling language component for creating one or more electronic model specifications is shown.

[0024] Figure 6 An embodiment of a support tool in the form of a graphical interface for facilitating the creation of one or more electronic model specifications is illustrated.

[0025] Figure 7 A hardware embodiment of a risk modeling and risk assessment system in the form of an integrated circuit chip (IC) is illustrated.

[0026] Figure 8 An embodiment is illustrated in which the risk modeling and risk assessment system is distributed and deployed as a service over a network.

[0027] Figure 9 is a flow chart depicting an embodiment of a method for modeling risk associated with an assessed system.

[0028] Figure 10a and Figure 10b is a flow chart depicting an embodiment of a method for assessing risk associated with an assessed system. DETAILED DESCRIPTION

[0029] As used herein, the term "comprise" or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

[0030] As used herein, the term "include" or variations such as "includes" or "including", will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

[0031] As used herein, the terms “may” or “can” will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

[0032] As used herein, the term "system under assessment" (SUA) refers to any system suitable for interfacing with the risk modeling and risk assessment system of the present disclosure. Non-limiting examples of SUAs include production systems, manufacturing systems, logistics systems, chemical plants / reactor systems, waste incineration systems, explosion-proof areas, construction sites, nuclear power plants, refineries, natural gas refineries, cybersecurity systems, automation and control systems, and one or more combinations of the foregoing. A SUA can be as small as a single machine, vehicle, and / or product. A SUA can refer to the entire system being assessed, regardless of its hierarchical or heteroarchical composition. A SUA can also include two or more systems that interact with each other during operation.

[0033] As used herein, the term "element of a SUA" may refer to a component of a SUA. Non-limiting examples include: a physical facility, such as a room, building, or shelf; a vehicle, such as an automated guided vehicle, forklift, or transporter; one or more machines; and / or a portion or section of a physical facility, vehicle, or machine. Elements of a SUA also include logical components, such as one or more of the following: an operating system, a network driver, a software application, a cryptographic service, a security function, and the like.

[0034] As used herein, the term "risk" includes security vulnerabilities, hazards, and / or confidentiality vulnerabilities, hazards. As used herein, the term "risk" also includes instances of security and / or confidentiality gaps relative to tolerable risk levels defined in current technical standards. Non-limiting examples of such risks include entrapment risk (i.e., an operator being trapped by one or more machines), explosion risk, fire risk, theft, unauthorized entry to a premises, unauthorized access to confidential information, etc.

[0035] As used herein, the term "risk-related characteristics" refers to attributes that are associated with one or more types of risk in the context of a SUA. For example, a risk-related characteristic could be a spark in a room with flammable materials that could cause an explosion risk, a vehicle in the path of an object / person that could cause a collision risk, etc. Risk-related characteristics can also include attributes used to prevent risks (e.g., safety features and confidentiality countermeasures), as well as general contextual information (e.g., the Earth's gravity).

[0036] As used herein, the term "natural language" includes one or more languages that humans have naturally developed in use, and may include languages such as English, Chinese, Japanese, German, etc. The term "natural language" may also include dialects and spoken languages.

[0037] As used herein, the term "system semantics" refers to semantics used in the context of SUA. System semantics includes syntax and its meaning to the system that can be understood by humans and also interpreted by a suitable computer compiler / processor.

[0038] As used herein, the term "condition" refers to a proposition expressed in natural or pseudo-natural language and mappable to system semantics. A proposition contains one or more expressions that may give rise to a risk. If a condition is evaluated to "true," then there is an unacceptable / unprotected risk associated with the condition. If a condition is evaluated to "false," then the risk associated with the condition is deemed "tolerable," and therefore no additional security and / or confidentiality measures are required.

[0039] As used herein, the terms "risk assessment" and "risk evaluation" are intended to be separate and independent from the design of a SUA. Furthermore, the terms "risk assessment" and "risk evaluation" are separate and independent from recommendations for mitigating any identified risks. Risk assessment and risk evaluation results are primarily used to verify and / or validate the design and identify nonconformities. Specifically, the term risk assessment encompasses risk analysis, evaluation, and / or risk reduction.

[0040] As used herein, the term "network" may be any means of providing communication between one or more devices and / or content stored elsewhere. As used herein, a network may be a personal area network, a local area network, a storage area network, a system area network, a wide area network, a virtual private network, and an enterprise private network. A network may include one or more gateways or no gateways. Network communications may be conducted via publicly available standard protocols or proprietary protocols.

[0041] As used herein, data communication over any network may be: (i) encoded or unencoded; (ii) encrypted or unencrypted; (iii) delivered via a wired network, a wireless network, or a combination of wired and wireless networks. Wireless communication may be accomplished by any practical means, including Wi-Fi 802.11 networks, Bluetooth TM A network or mobile phone network (such as 3G, 4G, LTE, and 5G). As used herein, the terms "connect," "connected," and "connecting" refer to a communication link between at least two devices and may be implemented as discussed in this paragraph.

[0042] As used herein, the terms "associate," "associated," and "associating" indicate a defined relationship (or cross-reference) between at least two items. This defined relationship can be expressed using one or more mathematical equations and / or formulas.

[0043] As used herein, the term "computing device" can be a single, standalone computer, such as a desktop or laptop computer, a thin client, a tablet computer, an embedded computer, or a mobile phone. The computing device can run a local operating system and store computer files on a local storage drive. The computing device can access files and applications through a gateway to one or more content repositories, which can host files and / or run virtual applications and generate a virtual desktop for the computing device.

[0044] As used herein, the term "server" may include a single standalone computer, a single dedicated server, multiple dedicated servers, and / or a virtual server running on a larger server network and / or cloud-based service. A server may also include a virtual machine and may include one or more computing services hosted on a cloud. A cloud may be a private cloud or a public commercial cloud.

[0045] As used herein, the term "runtime" is used in the context of computer processing terminology related to the implementation and execution of the present system. The runtime may or may not need to meet real-time requirements.

[0046] As used herein, the term "parameter" includes a variable, a constant, any measurable (quantitative or qualitative) quantity, and the derivative of any of the foregoing.

[0047] As used herein, the term "physical property" refers to a measurable property whose value describes the state of the SUA. Non-limiting examples of physical properties include temperature, color, pressure, distance, response time, computer memory consumption, etc.

[0048] As used herein, the term "functional performance" refers to the performance, accuracy, and compliance of a system output in response to an input. For example, a car's braking system may need to brake within a certain distance (output) when an input braking force is applied.

[0049] According to one aspect of the present disclosure, there is a system for modeling and assessing risks, comprising: at least one electronic model specification associated with a SUA, the electronic model specification including an application segment associated with at least one element of the SUA; the application segment including at least one of a security segment and a confidentiality segment associated with the at least one element; wherein at least one of the security segment and the confidentiality segment includes multiple risk-related characteristics; the multiple risk-related characteristics can be mapped from a natural language to system semantics, which are associated with physical or functional characteristics of the SUA; and a conditional segment specifying at least one condition associated with at least one of a security vulnerability and a confidentiality vulnerability being materialized; wherein at least one condition includes at least one of the multiple risk-related characteristics; an assessment engine, configured to evaluate at least one condition associated with at least one of the security vulnerability and the confidentiality vulnerability to determine whether a risk exists.

[0050] Figure 1A conceptual overview of the relationship between the risk modeling and assessment system 100 of the present disclosure and the SUA 1900 is shown. The system 100 can be arranged to communicate with the SUA 1900 to obtain information therefrom in order to, at least in part, derive input. The communication between the system 100 and the SUA 1900 can be wired or wireless. Alternatively, the system 100 may not communicate with the SUA 1900 and input to the system 100 may be provided manually. The system 100 is independent of the SUA 1900 in the sense that the SUA's operation is not affected by the presence, use, or interaction of the system 100. The system 100 is configured to model and assess the SUA 1900. If at least one risk exists, the system 100 models the at least one risk in the form of a list of conditions (such as a conjunctive list of conditions that cause the risk to become a reality) for the user to take action. If a risk is likely to occur due to multiple possibilities or the presence of multiple risks, the conjunctive list of conditions can be combined using disjunction. It should be appreciated that the list of conditions includes multiple risk-related characteristics.

[0051] like Figure 1 As shown in , the system 100 models and obtains parameters of the SUA 1900. In the event of any changes to the SUA, the system 100 can obtain the changed parameters during runtime. The system 100 can also be configured to obtain the changed parameters whenever a change event is detected, for example, via a trigger. Alternatively or additionally, the system 100 can also be configured to check the SUA 1900 at each predetermined time interval to detect any changes. It is contemplated that the system 100 can also be configured to check the SUA 1900 under various system states of the SUA 1900 (such as runtime / design phase / batch mode / online and offline / simulation states). The system states can correspond to various system life cycle stages of the SUA 1900.

[0052] like Figure 2 As shown in , the system 100 includes an electronic model specification 120 for modeling SUAs and associated security and / or privacy risks that may arise in the SUA 1900 .

[0053] It should be appreciated that each SUA may be different and that multiple electronic model specifications 120 may be created for each SUA depending on the operational scenario or additional components to be added to the SUA. Where multiple electronic model specifications 120 are created, each of the multiple electronic model specifications 120 may be viewed as or referred to as a fragment. It should be appreciated that multiple fragments of the electronic model specification 120 may be created and combined from different remote sources. Such combination may be performed by referencing one electronic model specification fragment, one or more other electronic model specification fragments. For example, a user such as an equipment supplier may choose to make the electronic model specification 120 available via a web resource such as a uniform resource locator (URL) of their company domain. The system 100 may be configured to detect any newly added electronic model specifications 120 for a remodeled SUA 1900. It should be appreciated that each electronic model specification fragment shares the same basic components as the other electronic model specification fragments.

[0054] The creation of the electronic model specification 120 can be performed manually (e.g., by a risk assessor, equipment supplier, system integrator, or risk assessment expert) or automatically (e.g., by a simulation engine or inference engine). A semi-automatic process for creating the electronic model specification through computer-assisted tools (such as a graphical editor) is also contemplated. In some embodiments, the inference engine may include one or more artificial intelligence (AI) engines to model the risk assessment expert(s).

[0055] An electronic model specification 120 is created based on a modeling language. The modeling language has predefined semantics, a set of rules, and a structure to facilitate the modeling of risk. The modeling language defines how one or more characteristics of the SUA 1900 can be recorded in a manner that meets requirements for expressiveness, correctness, and user understandability. The recorded characteristics can be relevant to risk assessments and / or evaluations.

[0056] The modeling language can be viewed as a metamodel that can be implemented in various specification language syntaxes. The metamodel can be managed by a component that forms part of an application programming interface (API). An example of a suitable grammar is Extensible Markup Language (XML), a markup language that defines a set of rules for encoding documents in a human-readable and machine-readable format. Other suitable grammars can include JavaScript Object Notation (JSON) and YAML Ain't Markup Language (YAML) grammars.

[0057] It is envisioned that the modeling language metamodel includes rules for defining valid electronic model specification documents in the desired language implementation. This means that modeling of risks (e.g., security vulnerabilities) is independent of the specification language, as long as a matching implementation parser or syntax analyzer is available. This flexibility allows the use of existing tools, frameworks, and concepts within the overall definition structure of the electronic model specification. For example, XML editors, document validation, XPath and XLink specifications, Resource Description Framework (RDF), etc. can be utilized.

[0058] The electronic model specification 120 includes an application section 140 associated with at least one element of the SUA. The application section 140 provides context for the general operation of each element of the SUA, including the scope of use of at least one element. For example, if the element of the SUA is a tool such as a chainsaw, the application section 140 provides the correct use of the tool. For example, using a chainsaw to stir liquids is not a correct use of the chainsaw. Therefore, in addition to the elements, the application context also needs to be modeled.

[0059] The application section 140 includes at least one of a security section 142 and / or a confidentiality section 144 associated with at least one element, wherein at least one of the security section 142 and the confidentiality section 144 includes a plurality of risk-related characteristics. The plurality of risk-related characteristics can be mapped from a natural language to system semantics, where the system semantics are associated with physical or functional characteristics of the SUA.

[0060] As an example of such a mapping of natural language to system semantics, consider the natural expression of the risk-related property "a person is in the path of an automated guided vehicle (AGV)". While easily understandable to a natural person (i.e., a human user recording such a risk), the expression must be transformed into machine-readable system semantics that are suitable for the context of the SUA. An example of such a mapping can be modeled in the form of a physical property, such as the distance between the person and the AGV. Whether the statement "the person is in the path of the AGV" is true depends on a predefined threshold (e.g., 3 meters - the distance between them). Such a predefined threshold may change or be affected by other physical properties, such as the speed or weight of the AGV. For example, if the speed of the AGV is high, then a longer distance between the person and the AGV may be defined as the threshold. Similarly, if the load carried by the AGV is heavier, then the required distance between the AGV and the person may be longer to prevent a collision.

[0061] Another example of a mapping is a natural representation of the risk-related characteristic "flying sparks." While sparks may be generated during the normal course of certain operations (such as a milling machine), depending on the context of the SUA, this may pose a safety risk, for example, in an open room without any appropriate barrier(s) to isolate the flying sparks. Whether the flying sparks will be assessed as a risk will depend on the modeling or mapping in the form of a functional characteristic, such as whether the appropriate barrier is closed or open.

[0062] The electronic model specification also includes a condition section 146 that specifies at least one condition associated with at least one of a security vulnerability and a confidentiality vulnerability becoming realized. The at least one condition includes at least one of a plurality of risk-related characteristics. As an example, the condition can be expressed as a conjunction list of conditions, as shown in Equation 1:

[0063] (person_is_in_path_of_agv)∧(agv_cannot_brake) (1)

[0064] Equation 1 is a simplified example of a hazard model. All elements within equation (1) must be evaluated to be true for the hazard to be effective or realized. The risk-related property "person_is_in_path_of_agv" can be defined by physical and / or functional components as explained. For example, the "in-path" proposition can be simply modeled as the distance between the person and the AGV path being less than a given threshold. The condition can be modeled using Equation 2, which defines a simplified "in_path_of" proposition based on two parameters (person, AGV). The condition is true when the distance between the person and the AGV path is less than a threshold. Symbols prefixed with a $' sign represent variables. It should be recognized that the complete hazard description is more detailed and the examples given below rely on SUA.

[0065] (in_path_of$person$AGV):=(<(distance(location($person)(path_of$AGV))$threshold) (2)

[0066] The risk-related characteristics "agv_cannot_brake" or "agv_cannot_brake_in_time" can be a function of the AGV's braking system, floor characteristics, and AGV weight. If multiple hazards exist in the SUA, they can be combined using disjunction (i.e., an "OR" operation). Any hazard could invalidate the compliance of the entire system.

[0067] Figure 3a 、 3b , 3c and 3d illustrate various embodiments of the electronic model specification 120. Figure 3a illustrates an example syntax of the electronic model specification 120 in XML format, Figure 3b Lists the top-level elements of the modeling language used to create electronic model specifications. Figure 3c Lists the basic language elements of the modeling language, and Figure 3d Lists the basic types of the modeling language's type system.

[0068] Figure 3b Illustrated are additional sections of the electronic model specification in addition to the application, security, privacy, and conditions sections. The additional sections may include a definition section and a world section.

[0069] The Definition section introduces default and user-defined constructs. For example, a modeling language may allow the definition of primitive elements (such as types of values) and composite elements (such as new types of robots).

[0070] The World section is a section of the electronic model specification 120 that lists any other relevant characteristics of the SUA being assessed that are neither unique risks nor mitigation factors. The World section includes at least one general characteristic of the SUA 1900. Such a general characteristic may not be directly related to any risk of the SUA, but may be a physical and / or functional characteristic that can affect the SUA's risk assessment. A non-limiting example of a general characteristic is the Earth's gravity.

[0071] Figure 3c A table of semantic language elements of the electronic model specification 120 is shown. One or more language elements can be used for risk modeling and definition. In particular, language element import can be used to reference external electronic model specification fragments.

[0072] Figure 3d Different types of tables are shown as part of the specification language used to create the electronic model specification 120 .

[0073] A solution to each condition that causes a security or confidentiality hazard as listed in the conditions section or defined within the security / confidentiality section can be found in a search or solution space. To this end, the system 100 includes an evaluation engine 160 to define the search space and evaluate the conditions as true / false answers. In some embodiments, the evaluation engine 160 includes a script evaluator 162 and a solver evaluator 164. In some embodiments, the evaluation engine can determine the acceptability of the SUA 1900 based on modeling the risk of the SUA 1900 as an optimization problem to reduce the overall computational complexity. It is contemplated that suitable algorithms may or may not use a search space. Non-limiting examples include evolutionary algorithms, such as genetic programming / algorithms; regression algorithms; neural networks; fuzzy logic systems, etc.

[0074] Script evaluator 162 combines inputs for solver evaluator 164. In some embodiments, script evaluator 162 operates to reduce the search space for each condition by, for example, replacing and removing redundant or duplicate solutions. For example, two or more solutions where the distance between the person and the AGV is less than a predefined threshold of equation (2) may evaluate the risk-related property "person_is_in_path_of_agv" as true. Script evaluator 162 operates to remove redundant solutions from the search space to reduce the computational resources required for evaluation.

[0075] As another example of reducing complexity or solution space, consider the AGV of equations (1) and (2). Assume there is a formula / mathematical expression to calculate the braking distance of the AGV (in meters), which is expressed as a function of three parameters: the current speed of the AGV, the effective weight of the AGV including the weight of any load carried by the AGV, and the braking force applied (i.e., f(speed, weight, force)). This formula outputs the distance required for the AGV to come to a complete stop. Assume there is a condition generated in the constraint solver: (f(speed, weight, force) < 2) means that the AGV must stop within 2 meters of the person. Calculating nonlinear functions in a constraint solver can be computationally expensive. If all parameters are known, then the script solver can simplify the formula or replace it completely with the result. Imagine that f evaluates to 1.5 meters. Then (1.5 < 2) is "true". It should be recognized that by simplifying the formula or replacing them completely, the script solver reduces the number of variables that the script solver must consider.

[0076] Solver evaluator 164 evaluates each condition as "true" or "false." If a condition is evaluated as "true," then there is a risk associated with the corresponding condition, and therefore the SUA cannot be accepted, i.e., a non-compliance is detected. In other words, solver evaluator 164 thus acts as a constraint solver, finding an assignment for each risk-related characteristic that will cause the entire condition to be evaluated as "true." The assignment found then automatically constitutes the argument as to why the SUA cannot be accepted.

[0077] The expected risk model may be expressed as a deterministic model, such as but not limited to a Satisfiability Modulo Theory solver (SMT) model. Furthermore, the assessment process is formally verifiable.

[0078] In some embodiments, the evaluation engine 160 may be configured to receive current or updated parameters from the SUA prior to evaluating each condition.In some embodiments, one or more risk-related characteristics may be mapped into constraints within the SMT model.

[0079] In some embodiments, a protection segment 147 may be developed in association with a safety segment and a prevention model 148 may be developed in association with a confidentiality segment. The protection measure (in the safety domain) or countermeasure (in the confidentiality domain) segment may be modeled similarly to a safety / confidentiality risk as a conjunction formula. Risk modeling languages define prevention in terms of the contradiction of risk components. Using equations (1) and (2) as an example, an effective safety function may ensure that the AGV is always able to brake or decelerate in time. This may be achieved by a safety function that reduces the AGV speed to invalidate the "agv_cannot_brake" condition. Another option may be a safety function that addresses the risk-related property "person_is_in_path_of_agv". The prevention model may ensure that the distance between a person and the AGV path never becomes too short (i.e., collision avoidance). This modeling methodology establishes a clear and traceable semantic relationship between a protection measure and a prevention that explains why it is effective for a given safety or confidentiality hazard.

[0080] In order for the mitigation to be effective, the system 100 ensures that each safeguard (formula) is itself satisfiable. This is another important requirement, as ineffective safeguards may result in a "false" rating for the SUA, thereby incorrectly rating the SUA as compliant even when one or more unprotected risks exist in the system. It should be appreciated that mitigation models can be used in conjunction with risk models to assess the compliance of SUAs.

[0081] In some embodiments, the form of the electronic model specification can be based on Figure 4 The components listed in take the form of an application programming interface (API) 400. The API 400 is organized into three categories: (1) interfaces 402, (2) runtimes 404, and (3) languages 406.

[0082] Components in the interface category define how the electronic model specification 120 and the evaluation engine 160 are packaged, used, and interfaced. The system configuration includes various settings, including environment settings such as modeling language configuration 411, input interpretation, execution path, log level, authentication, network settings, etc. The executable file 412 is a binary executable file compiled for the target platform for execution (i.e., SUA 1900). Several interaction modes are contemplated, including execution as a command line tool and as a web service. In addition, the executable file as a library can be embedded in or called by complementary tools such as system design tools or manufacturing execution systems (MES).

[0083] The components in the runtime category 404 enable execution of the system 100, i.e., they implement the algorithms of the system 100, including receiving parameters from the SUA, generating risk models associated with the SUA, and generating search spaces. The registration component 413 controls the set of language elements supported during the evaluation run. The registration component 413 allows generalization of language elements through aliases and types, which is a core feature of the extensibility of the language and methodology. The context component 414 implements the execution scope mechanism including defined types, variables and functions. The model collector component 415 implements the algorithm to create a risk model associated with the SUA, which is evaluated through two evaluation channels implemented by the script solver 416 and the model solver 417 respectively. The results of the evaluation are formatted and passed back to the caller through the configured interface.

[0084] The components of the modeling language class 406 implement the risk modeling language itself. A single electronic model specification fragment 418 is the root component from which all other components are derived in an object-oriented manner. The simplified implementation of the inheritance hierarchy tree begins with, for example, Figure 5 Each construct of the modeling language is implemented as a specialization of an electronic model specification fragment. Each component defines its contribution to the system model and a matching interpreter to construct the evaluation result.

[0085] Figure 5 An embodiment of modeling language components that structure the electronic model specification 140 or a portion (ie, a fragment) thereof based on object-oriented principles is shown. Figure 5 The relationships between the various components in the electronic model specification 140 are also depicted, including inheritance relationships. It should be appreciated that the arrow caps (shown as △) are simply overlapped to simplify the overview. Each inheritance relationship should be understood as a parallel line. Distinguishing features of inheritance relationships include the following:

[0086] The type system is fully configurable to suit the needs of SUA. This includes the ability to redefine what constitutes a "Boolean" type (e.g., true / false, on / off, one / zero, etc.). It is expected that any type can be redefined, modified, or excluded. The rigor of the modeling language ensures that this flexibility does not result in invalid statements.

[0087] The type "system" is not limited to the types allowed by typical constraint solvers. It is worth mentioning the modeling flexibility, expressiveness and usability of 100 Systems. In theory, all risk assessors can learn to express SUA models in the domain of constraint solvers. However, this may be impractical and counterproductive because many inconsistencies may arise. Among the many ways in which risk assessments can be mapped to constraint solvers, the present disclosure maps risk-related characteristics to a conjunction list of system semantics and conditions, and then to the constraint space, ensuring that the various expressions remain compatible and interoperable.

[0088] You can conceive of two or more types of variables to model different evaluation steps. Script variables (used to subsequently reduce the solution or search space via a scripted solver) can hold local or remote values, generalizing the concept of variables. Script variables hold values. Solver variables do not hold a single value, but rather reference a range of possible assignments. Therefore, they serve as search parameters for model evaluation steps.

[0089] It is expected that the concepts of safety and security can share many common features (e.g., the concepts of risk and prevention) but are also specifically designed to model their differences. For example, safety functions need to comply with target performance levels and safety integrity levels, while countermeasures need to comply with security levels.

[0090] The hierarchical structure is extensible, enabling features of the API 400, modules, libraries, and graphical editors to assist in the process of creating electronic model specifications.

[0091] In some embodiments, software extensions can be defined to extend the functionality of the base modeling language. There are at least two main categories of extensions: (1) content modeled in the modeling language itself, and (2) extensions to the modeling language that use the API 400. The first category is called a module, and the second category can be called a library. Modules are more portable but are limited to configuration. Libraries fully encompass modules and additionally allow for extensions of the language.

[0092] Modules can be a way to codify existing standards and dynamically import them during the assessment process. Thus, if a SUA should comply with a given standard, the user, who may be an assessor, can simply import the corresponding module(s). Standards are typically published by international standardization organizations such as ISO and IEC. For example, analyzing the requirements for safety-related control systems in ISO 10218-2, such as those shown in equation (3), can be converted into electronic model specification fragments by forming the conjunction and disjunction formulas discussed.

[0093] (No_SingleFault_may_lead_to_loss_of_safety_function)∧(SingleFault_shall_be_detected_before_next_demand)∧(SingleFault_triggers_safety_function_and_maintain_until_fault_is_corrected)∧(All_foreseeable_faults_shall_be_detected) (3)

[0094] Target performance requirements can also be expressed using the modeling language with the following syntax:

[0095]

[0096] Based on the aforementioned construction, the modeling language defines the structure and content of security and privacy profiles for SUA components. For example, a security profile can include one or more of the following: component type, security goals or thresholds, security measure classification, security measure characteristics, reliability requirements (performance level or reliability level of mechanical components), and availability over time.

[0097] The privacy profile may include one or more of the following: component type, privacy goals (eg, confidentiality, integrity, availability), privacy measure classification, privacy measure characteristics, privacy level requirements, availability over time.

[0098] While it is clear that electronic model specifications can be created using a basic text editor, depending on the language chosen for implementation, tool support can be introduced to ease the burden on the user. For example, there are several tools available for editing XML, JSON, and YAML documents, including syntax checkers, validation, and graphical representations.

[0099] Figure 6 An example of a dedicated editor in the form of a computer-aided design tool 600 provided to a user to aid in the modeling and assessment / evaluation of risk is shown. Figure 6 Illustrated is a sample prototype visualization of a 2D editor for managing factory layouts.

[0100] The 2D editor is used to create and manage electronic model specification documents. Using the 2D editor, the user can drag and drop elements of the SUA (such as equipment) onto the space 602. In the background, the editor manages the electronic model specification document and adds the required fragments to the SUA specification. Figure 6 The diagram depicts a fairly complex application, including several machines, robots, warehouses, shelves, personnel, and AGVs. Labeled areas 604, 606, and 608 represent hazardous areas that have been introduced or explicitly designated for the application. Labeled area 604 represents an oil pit, labeled area 606 represents a workbench, and labeled area 608 represents a conveyor belt.

[0101] An example of the effectiveness of system 100 can be observed in a narrow corridor 610. With only one AGV in the factory, the only area with an entrapment risk is "Rack 2" 612. If a person enters the "Rack 2" area 612 and AGV 614 enters after the person, the person will not be able to leave the Rack 2 area 612 and therefore has no escape route. This represents an unacceptable risk. This unacceptable risk can be prevented by the access control safety function of the rack. However, after adding another AGV 616 of the same type as the first AGV 614, a new danger zone appears in corridor 610. This may initially be surprising because only acceptable and certified systems are involved. However, a new hazard may arise where a person may be trapped between two AGVs along corridor 610. For human assessors, it may be difficult to identify such emerging hazards of multiple interacting systems.

[0102] In some embodiments, system 100 can be implemented directly in hardware, for example by using a field programmable gate array (FPGA) for a composable safety and security system. Each key component of the system can be embedded in or connected to an integrated circuit (IC) chip 700 (see Figure 7 ). IC chip 700 includes an electronic model specification and an embedded engine configured to perform the functions of assessment engine 160. The electronic model specification can be compiled by assessment engine 160 at runtime to form a risk model that can contain all relevant hazards and precautions of the component, including its safety and security profile.

[0103] In some embodiments, the system 100 may also be deployed as a service on the network 800 (see Figure 8 A node in the network 800 may host an assessment engine 160. This node provides an entry point for performing risk assessments. The electronic model specification 120 and associated fragments may be hosted by various network nodes 820 in the network 800. A non-limiting example of a node 820 is a vendor's website. The system 100 service engine 160 may merge or combine all electronic model specification fragments. The service engine may provide judgments on received documents as needed.

[0104] In some embodiments, the system can be implemented as a plug-in to a design tool to assess SUA compliance throughout various stages of design (see, e.g., Figure 6 editor).

[0105] In normal operation, the system 100 may not be considered or provided as an active safety function and / or privacy countermeasure in operation to ensure independence from SUA. However, it is contemplated that the system 100 has the ability to provide useful information on existing gaps so that they can be remediated by the user in a reactive manner.

[0106] Nevertheless, the system 100 can potentially rise to the level of active safety functionality and proactively ensure the safety and confidentiality of the SUA, wherein independence can still be achieved.

[0107] According to another aspect of the present disclosure, there is a method for modeling risk associated with a SUA. Figure 9 An embodiment of method 900 is shown, comprising the following steps: (a.) defining an application segment associated with at least one element of the SUA (step s902); (b.) defining at least one of a security segment and a confidentiality segment associated with the at least one element within the application segment, wherein at least one of the security segment and / or confidentiality segment includes a plurality of risk-related characteristics (step s904); (c.) mapping the plurality of risk-related characteristics between natural language to system semantics, wherein the system semantics are associated with physical or functional characteristics of the SUA (step s906); (d.) specifying at least one condition associated with at least one of the security vulnerability and confidentiality vulnerability becoming realized (step s908); and forming an electronic model specification (step s910).

[0108] In some embodiments, the method 900 may include the step of specifying a definition section that defines a plurality of common elements associated with the SUA (step s912).

[0109] In some embodiments, the step of defining the application segment also includes the step of specifying a world segment (step s914), where the world segment itself includes at least one non-risk-related characteristic. Examples of non-risk-related characteristics include physical laws and environmental parameters such as temperature and pressure. While non-risk-related characteristics may not be risk-related characteristics, they can serve as thresholds for a risk to materialize. For example, a temperature threshold can be set such that exceeding the temperature threshold will cause an explosion risk to materialize.

[0110] Method 900 may be supplemented with method 1000 for assessing risk associated with SUA (SUA). Figure 10a and Figure 10b Method 1000 begins with the step of generating or creating an electronic model specification (step s1002) according to method 900. Method 1000 then proceeds to the step of configuring system 100 (step s1004). The configuration determines the boundary conditions for performing the evaluation (e.g., which features are used in performing the evaluation, available interface types, execution mode, etc.).

[0111] After the configuration is complete, the next step involves the step of parsing the electronic model specification document according to the rules of the modeling language (step s1006) to generate the specification 120 associated with the SUA. The parsing step includes the step of interpreting the parsed document to process the definitions specified in the electronic model specification (step s1008). The structure and implementation of the modeling language produce modular and extensible specifications. For example, the electronic model specification can define custom types to model the SUA. The definition may also modify the way values are interpreted (for example, metric versus imperial unit systems). The parsing step may also include the step of combining or merging all referenced specification fragments through an import function (step s1010). It should be recognized that the referenced electronic model specification fragments may be locally available or may be remotely available. For example, an equipment supplier may choose to provide the electronic model specification (fragment) via a unique URI of its company domain. Any loaded fragment will be recursively evaluated using the same process. It should be recognized that if there are no specification fragments to import, the merging step can be skipped.

[0112] After all relevant (or necessary) electronic model specifications have been imported, the most general version of the risk model is available. The risk model then undergoes script evaluation and solver evaluation to identify one or more unprotected risks associated with the SUA. The following steps s1012 and s1014 facilitate adaptive and optimized risk assessment. First, all reference parameters from the SUA are collected (step s1012) so that the latest or most recent parameters of the SUA are considered at runtime. This may include current operating conditions, tasks to be performed, and parameters derived or predicted from simulations, etc. Once the data collection process is complete, all derived expressions (conjunction formulas) can be processed by script evaluation and constraint solver (step s1014). For example, the expression "total weight of the AGV" can be an expression of the sum of its components and its current transport load. Before solver evaluation, the "script" evaluation step first reduces the computational complexity associated with, for example, whether the total weight of the AGV exceeds a predetermined constraint (e.g., a weight limit). Traditional constraint solvers suffer from a huge increase in state space when applied to large real-world problems. The "script" evaluation stage reduces the complexity of the constraint solver.

[0113] After the script and solver evaluation, a deterministic model, such as an SMT model, is generated (step s1016), which represents the inputs for which the solver found unguarded risks. For example, the model solver may find assignments to solver variables that would constitute an unacceptable probability, thereby constituting a hazard that could cause harm. (For example, "the user is standing in front of the machine" and "the machine is on" and "the door is open" and "the user has one hand free" and then "the user could be cut by rotating equipment"). The results of the model solver phase are parsed and an assessment report is generated. Report generation is flexible to meet the needs of further automated processing (e.g., by design tools) or interpretation by human assessors.

[0114] Method 900 and / or method 1000 can be implemented on a computer-readable medium such as one or more computer devices. As an example, generating an electronic model specification via a text editor or a graphical editor can be performed on a computing device, and the evaluation steps in method 1000 can be implemented on a host server. In some embodiments, to prevent the possibility of tampering with the evaluation process and results, method 900 and / or method 1000 can be implemented in a blockchain network.

[0115] It is contemplated that the system 100 and methods 900, 1000 may be used to support various use cases such as:

[0116] Risk Assessment—System 100 can be integrated into traditional workflows for security and safety assessments. It replaces the traditional approach of documenting risks (hazards and / or threats) and mitigation measures or countermeasures, formalizing and restructuring the risk assessment process. System 100 formalizes documentation, rather than simply human-readable documents, and provides a list of conjunction formulas, enabling automated assessments. It is anticipated that system 100 can be part of R&D activities used to design and manufacture components, products, and subsystems for use in the IIoT context.

[0117] Runtime Risk Monitor—System 100 can be deployed with system applications that have been validated for safety and security to dynamically reassess the compliance of SUAs as their parameters change. The primary value comes from the optimizations made possible by parameterization and relaxing worst-case assumptions. Even if system 100 does not accept a SUA, the operator may still decide, at their discretion, to run it anyway and assume responsibility for the identified risks.

[0118] Black Box Assessment—System 100 can be used in a black box assessment mode. In this mode, portions of the electronic model specification are available remotely and / or can be encrypted, such as with binary encryption. A user of a piece of equipment that forms part of the original SUA electronic model specification may decide to modify a portion of the equipment. Such modifications may include replacing one or more motors or adding a new piece of equipment. However, the user may not have access to the original SUA's risk assessment. This may be for intellectual property protection or simple economic reasons. System 100 allows the user to proceed in any manner. Using a modeling language, the user can create a fragment of the electronic model specification that only contains their changes. Because the electronic model specification fragment includes additional conjunction conditions representing the risks attributed to the new equipment, the assessment engine 160 can reassess the entire system 100 using the newly added electronic model specification fragment without disclosing any details of the original system 100. For example, a modification might be rejected because the inclusion of a new motor would consume more power, which would in turn increase the temperature of the power supply, creating unprotected risks. The original SUA vendor can define the level of detail in the assessment report. If the vendor does not want to disclose the power supply specifications, the system can simply reject the modification without further explanation.

[0119] Auxiliary Tools - The method 900 for risk modeling and / or the method 1000 for risk assessment can be integrated with existing system design tools. Figure 6 The computer-aided tool shown in [ 100 ] can be used as an example. At various stages of system design, system 100 can be invoked to gather insights into the acceptability of SUA assumptions. The assessment may be indicative only, as the electronic model specifications 120 for each stage may not yet be complete and therefore not approved by TIC experts. In some embodiments, methods 900 and 1000 will only be able to determine if SUA 1900 has unprevented risks but will not be able to propose solutions. However, it will be able to determine solutions as long as the solutions are modeled in a modeling language.

[0120] Scenario Testing and What-If Analysis - By providing parameterized conformance assessments, the system 100 and methods 900, 1000 can be used to model and evaluate different what-if scenarios and explore the impact of modifications on the acceptability of the SUA. Such studies can also support improvements or optimizations to the system design, for example, by highlighting whether acceptability is achieved only within a narrow parameter space.

[0121] In some embodiments, method 900 and / or method 1000 may be encoded in the form of software computer code or a computer program. The computer program includes processor-executable instructions stored on at least one non-transitory computer-readable medium. The computer program may also include or rely on stored data. The computer program may include a basic input / output system (BIOS) that interacts with the hardware of the special-purpose computer, device drivers that interact with specific devices of the special-purpose computer, one or more operating systems, user applications, background services, background applications, etc.

[0122] Those skilled in the art will also appreciate that variations and combinations of the above features, rather than substitutions or replacements, may be combined to form yet other embodiments falling within the intended scope of the present invention.

Claims

1. A system for assessing and modeling the risk of an assessed system (SUA), the system comprising: a) a plurality of electronic model specification fragments in a modeling language residing at one or more first network nodes, i) wherein the modeling language comprises a plurality of rules defining each electronic model specification fragment in a desired language implementation; as well as ii) wherein each electronic model specification fragment comprises: 1) Define sections, including default structures and user-defined structures; 2) Application section, 2.1) wherein the application section includes at least one element of SUA; 2.2) wherein the at least one element includes at least one of a secure section and a confidential section; 2.3) wherein the at least one of the secure section and the confidential section comprises a plurality of risk-related characteristics; the plurality of risk-related characteristics are mapped from natural language to system semantics; and 2.4) wherein the system semantics include physical or functional characteristics of the SUA; and 3) a condition section specifying at least one condition for at least one of a security risk and a confidentiality risk to materialize; wherein the at least one condition includes at least one risk-related characteristic of the plurality of risk-related characteristics; b) a computer-aided tool for managing the plurality of electronic model specification fragments to create an electronic model specification of the SUA; and c) an evaluation engine residing at the second network node, the evaluation engine being configured to, with respect to the electronic model specification of the SUA, evaluate the at least one condition to determine whether an unprotected risk exists, i) wherein the evaluation engine is configured to receive a reference parameter set from the SUA to define a search space for the at least one condition; and ii) wherein the defined search space represents a set of solutions that include one or more unprotected risks; and iii) wherein the system is arranged to communicate with a SUA to receive reference parameters from the SUA, and the SUA is an industrial asset comprising a production system or a manufacturing system.

2. The system of claim 1, wherein the defined search space is reduced by replacing and removing redundant or duplicate solutions.

3. The system of claim 1, wherein the application section comprises a world section, the world section comprising at least one universal characteristic. 4 . The system of claim 1 , wherein each of the plurality of electronic model specification segments is associated with at least one of equipment, facilities, infrastructure, and vehicles of the SUA.

5. The system of any one of claims 1 to 4, wherein the search space is represented as a deterministic model.

6. The system of claim 5, wherein the deterministic model is a Satisfiability Modulo Theory solver (SMT) model.

7. The system of claim 1, wherein the computer-aided tool is one of a text editor, a graphic editor, and a 2D editor.

Images