KR20230095565A - APPARATUS AND METHOD FOR DEPENDENCY AND SECURITY QUANTIFICATION OF IoMT SYSTEM BASED ON CLOULD-FOG-EDGE CONTINUUM USING HIERACHICAL MODEL - Google Patents

Abstract

The present invention relates to an apparatus and method for quantifying dependency and security of an Internet of Medical Things (IoMT) system based on a cloud-fog-edge continuum using a hierarchical model. An FT system model processing unit including an FT (Fault Tree) system model (Ψ) capturing the IoMT system architecture, an FT subsystem model (Δ) disposed in the middle and modeling the architecture of a subsystem in each of the heterogeneous member systems An FT subsystem model processing unit including an FT subsystem model processing unit, and a state-based model processing unit including a state-based model (Φ) disposed at the bottom and capturing operation behaviors by failure modes and recovery strategies for components in each of the subsystems. includes

Description

Apparatus and method for quantifying dependency and security of cloud-fog-edge continuum based IoMT system using layer model

The present invention relates to an Internet of Medical Things (IoMT) system, and more particularly, to cloud-fog-edge using a layer model capable of quantifying reliability and security of an IoMT system using a layer model. An apparatus and method for quantifying dependency and security of a continuum-based IoMT system.

Along with the development of next-generation IT technology, the quality and accessibility of medical services are rapidly improving. At the center of this is the Internet of Medical Things (IoMT) technology that comprehensively analyzes personal medical information collected from various paths, such as patients, medical service providers, and insurance companies. IoMT technology collects digitized medical information and comprehensively monitors the patient's health status, enabling diagnosis that focuses on disease prediction beyond treatment and providing personalized treatment.

IoMT has emerged in recent years as a computing infrastructure that opens up possibilities for medical treatment and disease diagnosis. In particular, IoMT is expected to revolutionize digital health due to the global aggressive virus pandemic, overcrowding in medical centers and hospitals, and overloading of the general health system and healthcare workers in prevention and treatment. 'e-Health' is an IoMT infrastructure composed of a huge amount of heterogeneous Internet-connected medical sensors/devices to reduce the workload of the current enormous autonomous medical monitoring tasks and to preemptively respond to the new virus pandemic with infinite to zero latency. do.

Reliability and security requirements for IoMT infrastructure are higher than for other IoT systems. Reliability and security are key concerns for the growth of IoT-based healthcare infrastructure due to the nature of patients' sensitive and confidential personal and health information. Therefore, a standardized architecture that balances reliability and safety requirements with security and privacy must be put in place to achieve a level of reliability in IoT-based healthcare infrastructure.

The computing power and storage capabilities of the IoMT infrastructure are likely to rely on the existing computing backbone, which is a powerful computing paradigm (e.g. cloud/fog/edge (CFE)), while sensing and data collection are medical sensors/devices at the edge of the entire network. depend on the pervasiveness and ubiquity of Additionally, the concept of cloud-fog-edge interoperability and/or integration in medical IoMT infrastructures has been gradually adopted in practice to resonate the existing computing performance and storage capabilities of individual computing paradigms while reducing their drawbacks when integrated. An IoMT infrastructure with CFE interoperability/integration for medical monitoring can face devastating challenges due to internal failures due to software/hardware failures or external failures due to cyber attacks. For example, DDoS attack can cause communication interruption, continuous downtime of applications/services that are sensitive to the operation time of the entire medical system, resulting in financial loss and blocking of local medical infrastructure.

Therefore, although there have been studies on modeling and evaluation of reliability, availability, and security measures of computing paradigms and physical infrastructures using probabilistic models, the focus has been on modeling and analysis of reliability and security measures for cloud systems. In a recent study, a dual-layer model was presented to analyze the availability of e-health IoMT infrastructure, and the study was extended to propose an additional SPN model to consider performance along with availability measurement. These studies only considered simple failure modes and recovery strategies of cloud, fog, and edge member systems, and did not present a comprehensive study of IoMT for medical monitoring.

Therefore, a comprehensive study on the stability, availability, and security evaluation of a specific e-health IoMT infrastructure for medical monitoring consisting of a cloud-fog-edge continuum three-layered structure was required.

Japanese Patent Registration No. 6137175 (May 12, 2017) Korean Patent Registration No. 10-2293195 (2021.08.18)

An embodiment of the present invention is to provide an apparatus and method for quantifying the reliability and security of an IoMT system based on a cloud-fog-edge continuum using a layer model capable of quantifying the reliability and security of the IoMT system using the layer model. .

An embodiment of the present invention is a cloud-fog-edge continuum-based IoMT system using a layer model that can quantify the reliability and security of an IoMT infrastructure that relies on the unified physical architecture of the cloud-fog-edge (CFE) computing paradigm. It is intended to provide a device and method for quantifying dependency and security.

An embodiment of the present invention is a hierarchical model capable of quantifying the reliability and security of an IoMT infrastructure by integrating various security defects for subsystems using a Fault Tree (FT) system model, an FT subsystem model, and a state-based model. It is intended to provide an apparatus and method for quantifying the dependencies and security of an IoMT system based on a cloud-fog-edge continuum using .

Among the embodiments, the device for quantifying the dependency and security of the Internet of Medical Things (IoMT) system based on the cloud-fog-edge continuum is a Fault Tree (FT) that captures the entire IoMT system architecture, which is placed at the top and consists of heterogeneous member systems. ) an FT system model processing unit including a system model (Ψ), an FT subsystem model processing unit including an FT subsystem model (Δ) disposed in the middle and modeling the architecture of a subsystem in each of the heterogeneous member systems, and A state-based model processing unit including a state-based model (Φ) disposed at the bottom and capturing operation behaviors according to failure modes and recovery strategies for components in each of the subsystems.

The FT system model Ψ may include a FT model set representing an FT graph interconnecting FT models for the heterogeneous member systems.

Each of the FT models includes a subsystem model set for the subsystem, and a subsystem model in the subsystem model set may correspond to a graph of an FT model representing an architectural configuration of a member system.

The FT subsystem model Δ may include a set of individual FT models of the subsystem, and each of the individual FT models may include a set of component models.

The state-based model Φ may include a set of individual Continuous-Time Markov Chain (CTMC) models of the component.

Among the embodiments, the cloud-fog-edge continuum-based Internet of Medical Things (IoMT) system's dependency and security quantification method using a hierarchical model is placed at the top and captures the entire IoMT system architecture composed of heterogeneous member systems. An FT system model processing step including an FT (Fault Tree) system model (Ψ), an FT subsystem model (Δ) disposed in the middle and modeling the architecture of a subsystem in each of the heterogeneous member systems. a system model processing step, and a state-based model processing step including a state-based model (Φ) disposed at the bottom and capturing operating behaviors by failure modes and recovery strategies for components in each of the subsystems. .

The FT system model Ψ may include a FT model set representing an FT graph interconnecting FT models for the heterogeneous member systems.

Each of the FT models includes a subsystem model set for the subsystem, and a subsystem model in the subsystem model set may correspond to a graph of an FT model representing an architectural configuration of a member system.

The FT subsystem model Δ may include a set of individual FT models of the subsystem, and each of the individual FT models may include a set of component models.

The state-based model Φ may include a set of individual Continuous-Time Markov Chain (CTMC) models of the component.

The disclosed technology may have the following effects. However, it does not mean that a specific embodiment must include all of the following effects or only the following effects, so it should not be understood that the scope of rights of the disclosed technology is limited thereby.

An apparatus and method for quantifying dependency and security of an IoMT system based on a cloud-fog-edge continuum using a layer model according to an embodiment of the present invention can quantify reliability and security of an IoMT system using a layer model.

An apparatus and method for quantifying dependencies and security of an IoMT system based on a cloud-fog-edge continuum using a hierarchical model according to an embodiment of the present invention is an IoMT infrastructure dependent on a unified physical architecture of a cloud-fog-edge (CFE) computing paradigm. The reliability and security of can be quantified.

An apparatus and method for quantifying dependency and security of an IoMT system based on a cloud-fog-edge continuum using a hierarchical model according to an embodiment of the present invention uses a fault tree (FT) system model, an FT subsystem model, and a state-based model. By integrating various security failures for subsystems, the reliability and security of the IoMT infrastructure can be quantified.

1 is a diagram illustrating an IoMT system based on a cloud-fog-edge continuum.
2 is a diagram illustrating an apparatus for quantifying dependency and security of an IoMT system based on a cloud-fog-edge continuum using a layer model according to the present invention.
FIG. 3 is a diagram illustrating the hierarchical modeling and analysis framework proposed in FIG. 2 .
FIG. 4 is a diagram illustrating a hierarchical modeling and analysis framework algorithm for the IoMT infrastructure proposed in FIG. 2 .
5 is a flowchart illustrating a method for quantifying dependency and security of an IoMT system based on a cloud-fog-edge continuum using a layer model according to the present invention.
6 is a diagram showing a hierarchical model.
7 is a diagram showing top-level Fault Tree (FT) models of IoMT infrastructures having different configurations.
8 is a diagram showing a top-level FT model of an IoMT infrastructure according to operating scenarios.
9 is a diagram showing FT models of member systems.
10 is a diagram showing an FT model of subsystems.
11 is a graph showing reliability of IoMT infrastructure in default parameters.
12 is a graph showing reliability analysis of IoMT infrastructure with configuration changes.

Since the description of the present invention is only an embodiment for structural or functional description, the scope of the present invention should not be construed as being limited by the embodiments described in the text. That is, since the embodiment can be changed in various ways and can have various forms, it should be understood that the scope of the present invention includes equivalents capable of realizing the technical idea. In addition, since the object or effect presented in the present invention does not mean that a specific embodiment should include all of them or only such effects, the scope of the present invention should not be construed as being limited thereto.

Meanwhile, the meaning of terms described in this application should be understood as follows.

Terms such as "first" and "second" are used to distinguish one component from another, and the scope of rights should not be limited by these terms. For example, a first element may be termed a second element, and similarly, a second element may be termed a first element.

It should be understood that when an element is referred to as being “connected” to another element, it may be directly connected to the other element, but other elements may exist in the middle. On the other hand, when an element is referred to as being "directly connected" to another element, it should be understood that no intervening elements exist. Meanwhile, other expressions describing the relationship between components, such as “between” and “immediately between” or “adjacent to” and “directly adjacent to” should be interpreted similarly.

Expressions in the singular number should be understood to include plural expressions unless the context clearly dictates otherwise, and terms such as “comprise” or “having” refer to an embodied feature, number, step, operation, component, part, or these. It should be understood that it is intended to indicate that a combination exists, and does not preclude the possibility of the presence or addition of one or more other features, numbers, steps, operations, components, parts, or combinations thereof.

In each step, the identification code (eg, a, b, c, etc.) is used for convenience of explanation, and the identification code does not describe the order of each step, and each step clearly follows a specific order in context. Unless otherwise specified, it may occur in a different order than specified. That is, each step may occur in the same order as specified, may be performed substantially simultaneously, or may be performed in the reverse order.

The present invention can be implemented as computer readable code on a computer readable recording medium, and the computer readable recording medium includes all types of recording devices storing data that can be read by a computer system. . Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tape, floppy disk, and optical data storage devices. In addition, the computer-readable recording medium may be distributed to computer systems connected through a network, so that computer-readable codes may be stored and executed in a distributed manner.

All terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present invention belongs, unless defined otherwise. Terms defined in commonly used dictionaries should be interpreted as consistent with meanings in the context of the related art, and cannot be interpreted as having ideal or excessively formal meanings unless explicitly defined in the present application.

1 is a diagram illustrating an IoMT system based on a cloud-fog-edge continuum.

Cloud computing means processing and accessing data over the Internet rather than on hard drives or local servers. Edge computing is a distributed computing model that collects data from the edge of the network and processes that data in real time. Fog computing may seem very similar to edge computing as it involves moving processing closer to the location where the data is collected, but data is sent from the point of collection to a gateway for processing and then back to the edge for processing. is transmitted Fog computing uses edge devices and gateways with LANs for processing, combining cloud capacity with the ability to run applications at the edge, acting as a bridge and combining the cloud and the edge.

The IoMT infrastructure represents the reliability of real-time medical services by integrating these cloud-fog-edge operations. Here, fog computing distributes the performance and storage capabilities of cloud computing to the computing network edge in local areas (e.g., hospitals, homes, shopping malls, etc.) to achieve high levels of data processing efficiency and latency. Where fog computing serves primarily as an intermediary between the cloud center and the edge of the IoT infrastructure for local data processing and aggregation, edge computing at the edge of the computing network provides for the processing of things (connected objects) with standardized data processes embedded in them. depend on Edge (e.g., smartphones, smart objects, wearable devices, etc.) or edge devices (e.g., IoT gateways, edge routers, IoT sensors/devices, etc.) provide high-speed data processing and collection and response times for most real-time services and medium-use applications. greatly shorten

The IoMT system architecture aims to provide sufficient information about member systems, subsystems and components. The present invention presents layer modeling and analysis for quantifying the reliability, availability and security of an IoMT infrastructure whose architecture consists of a cloud-fog-edge continuum triple layer structure.

2 is a diagram illustrating an apparatus for quantifying dependency and security of an IoMT system based on a cloud-fog-edge continuum using a layer model according to the present invention.

Referring to FIG. 2 , the apparatus 100 for quantifying dependency and security may include an FT system model processing unit 110 , an FT subsystem model processing unit 130 and a state-based model processing unit 150 .

The FT system model processing unit 110 may include a Fault Tree (FT) system model ψ that is placed at the top and captures the entire IoMT system architecture composed of heterogeneous member systems. Here, the heterogeneous member systems may correspond to cloud computing, fog computing, and edge computing, respectively.

The FT system model ψ may include a set of FT models representing FT graphs interconnecting FT models for heterogeneous member systems. Here, each of the FT models may include a subsystem model set for a subsystem in each of the heterogeneous member systems. Subsystem models in the subsystem model set may correspond to graphs of FT models representing the architectural configuration of member systems.

The FT subsystem model processing unit 130 may include an FT subsystem model Δ that is disposed in the middle and models the architecture of a subsystem in each of the heterogeneous member systems. Here, the FT subsystem model Δ may include a set of individual FT models of the subsystem. Each of the individual FT models may include a set of component models.

The state-based model processing unit 150 may include a state-based model φ that is disposed at the bottom and captures operation behaviors according to failure modes and recovery strategies for components in each subsystem. Here, the state-based model φ may include a set of individual Continuous-Time Markov Chain (CTMC) models of components.

The hierarchical model of the IoMT infrastructure can be represented as a graph of {ψ, Δ, φ}. First, the FT system model (ψ) includes a set of FT models (Z), and the set of FT models (Z) is as follows.

Z = {ξ ₁ ,... ,ξ _l ,... ,ξ _n ,ξ _ft }, (l = 1…n)

는 멤버 시스템의 FT 모델을 서로 연결하는 전체 FT 그래프를 나타낸다. 차례로, 멤버 시스템의 각 FT 모델(ξ_l)은 멤버 시스템 모델(

)의 서브시스템 모델의 전체 개수가

이라는 가정 하에 서브시스템 모델 집합 {

,...,

,...,

,

} (

= 1...

)을 포함할 수 있다. 여기서,

는 FT 모델

의 그래프로 멤버 시스템

의 아키텍처 구성을 나타낼 수 있다.where n is a specific number of member systems,

denotes the entire FT graph connecting the FT models of the member systems to each other. In turn, each FT model (ξ _l ) of a member system is a member system model (

), the total number of subsystem models in

Set of subsystem models under the assumption that

,...,

,...,

,

} (

= 1...

) may be included. here,

is the FT model

as a graph of a member system

can represent the architectural composition of

의 서브시스템 모델들은 {

,...,

,...,

}이며, 여기서 i는 멤버 시스템의 모델

에서 서브시스템 모델들의 갯수를 나타낸다. 멤버 시스템의 서브시스템 모델들

은 {

,...,

,...,

}이며, 여기서 j는 멤버 시스템의 모델

에서 서브시스템 모델들의 갯수를 나타낸다. 특정 멤버 시스템

(또는 서브시스템 모델 집합 {

,...,

,...,

,

})의 계산된 관심 출력은

이다. 반면, 전체 모델의 궁극적인 관심 출력은 결국 멤버 시스템 모델들의 이전에 생성된 모든 출력

(

= 1...

)으로 계산된

라고 할 수 있다. 특정 서브시스템 모델

과 관심 출력(

라고 함)은 각각 중단 모델에서 계산될 수 있다.member system model

The subsystem models of {

,...,

,...,

}, where i is the model of the member system.

Indicates the number of subsystem models in . Subsystem models of member systems

silver {

,...,

,...,

}, where j is the model of the member system.

Indicates the number of subsystem models in . specific member system

(or set of subsystem models {

,...,

,...,

,

}), the computed output of interest is

am. On the other hand, the ultimate output of interest of the entire model is eventually all previously generated outputs of the member system models.

(

= 1...

) calculated as

can be said Specific subsystem model

and the output of interest (

) can be calculated in each interruption model.

,...,

,...,

}을 포함하며, 여기서

= 1...

및

= 1...

이다. 특히, 특정 서브시스템

을 나타내는 모델은

이며, 이는 차례로 구성요소 모델들의 집합 {

,...,

,...,

,

}을 포함한다. 여기서,

= 1,...,

는 서브시스템에서 해당 구성요소의 인덱스이고,

은 서브시스템

의 구성요소 갯수이고,

는 이들 구성요소 모델의 FT 그래프 설명이다. 특정 서브시스템

의 계산된 관심 출력은

라고 한다. 구성요소 모델

및 그 관심 출력은 각각 가장 하단 모델에서 계산될 수 있다.Second, the FT subsystem model (Δ) is a set of individual FT models of the aforementioned subsystem {

,...,

,...,

}, where

= 1...

and

= 1...

am. In particular, certain subsystems

A model representing

, which in turn is a set of component models {

,...,

,...,

,

}. here,

= 1,...,

is the index of that component in the subsystem,

silver subsystem

is the number of components of

is the FT graph description of these component models. specific subsystem

The calculated interest output of

It is said. component model

and its output of interest can be computed in the bottommost model, respectively.

,...,

,...,

}의 개별 CTMC 모델들의 집합을 포함한다. 여기서

= 1···

,

= 1 ···

, 및

= 1,...,

이다. 특정 구성요소

의 CTMC 모델은

라고 하고, 관심 출력은

로 표시된다.Thirdly, the state-based model (Φ) has the aforementioned components {

,...,

,...,

} contains a set of individual CTMC models. here

= 1...

,

= 1 ...

, and

= 1,...,

am. specific component

The CTMC model of

, and the output of interest is

is indicated by

FIG. 3 is a diagram illustrating the hierarchical modeling and analysis framework proposed in FIG. 2 .

의 인덱스이다.

,...,

,...,

은 각각 멤버 시스템들

,...,

,...,

에 존재하는 서브시스템의 수이다. (

= 1,...,

), (i₂ = 1,...,

),..., (

= 1, ...,

),..., (

= 1, ...,

) 표기들은 해당 서브시스템들

,

,...,

,...,

을 나타내는 인덱스들이다.

,...,

,...,

표기들은 각각 위에서 언급한 서브시스템들

,

,...,

,...,

에 존재하는 구성요소의 총 수이다.

,...,

...,

표기들은 서브시스템들에서 해당 구성요소

,...,

,...,

의 인덱스들이다. 또한,

는 해당 구성요소

의 Markov 모델이고 계산할 관심 출력은

이다.

는 서브시스템

의 FT 모델에 대한 설명이며 계산할 관심 출력은

이다. 마지막으로,

는 전체 인프라 구조 FT 모델에 대한 설명이고

는 전체 IoMT 인프라 구조의 관심 출력 측정값이다.In Figure 3, n is the number of member systems in the IoMT infrastructure, l = 1... n is the corresponding member system

is the index of

,...,

,...,

are each member systems

,...,

,...,

is the number of subsystems present in (

= 1,...,

), (i ₂ = 1,...,

),..., (

= 1, ...,

),..., (

= 1, ...,

) notation indicates the corresponding subsystem

,

,...,

,...,

are indices representing

,...,

,...,

The notations represent the subsystems mentioned above, respectively.

,

,...,

,...,

is the total number of elements present in

,...,

...,

Notations indicate the corresponding component in the subsystems.

,...,

,...,

are the indices of also,

is the corresponding component

is a Markov model of and the output of interest to compute is

am.

is the subsystem

is a description of the FT model of and the output of interest to be computed is

am. finally,

is a description of the overall infrastructure FT model and

is the measure of the output of interest of the entire IoMT infrastructure.

,

,

}을 기반으로 IoMT 인프라에 대한 관심 출력 측정값의 계산 및 분석을 수행하기 위해, 제안된 모델링 및 분석 프레임워크 알고리즘이다. FIG. 4 is a diagram illustrating the hierarchical modeling and analysis framework algorithm for the IoMT infrastructure proposed in FIG. 2, and the hierarchical model {

,

,

} based on the proposed modeling and analysis framework algorithm to perform the calculation and analysis of the output measure of interest for the IoMT infrastructure.

을 계산하기 위한 입력 파라메터의 실제값과 같은 IoMT 인프라 구조의 충분한 정보를 제공한다고 가정한다. 빈 집합 초기화는 멤버 시스템(

), 서브시스템(

) 및 기본 구성요소(

)의 집합에 대해 처음에 수행된다. 3개의 메인 루프는 각각 모든 멤버 시스템, 서브시스템 및 구성요소를 탐색하는 데 사용된다. 첫 번째 루프는 1에서 n까지 하나씩 변화하는 인덱스 l로 형성되며, 여기서 IoMTStructure의 두 입력 변수와 해당 태그 memSystem의 함수 count에 의해 멤버 시스템의 수 n이 미리 계산된다. 두 번째 루프는 1에서 m_l까지 하나씩 변하는 인덱스 i_l을 사용하여 수행된다. 여기에서, 1) 멤버 시스템

에서 서브시스템들의 총 수 m_l는

의 두 입력 파라메터와 태그 subSystem을 사용하는 함수 cont에 의해 계산되고, 2) 멤버 시스템

은 두 입력 파라메터 IoMTStructure와 태그 memSystem으로 함수 extract에 의해 미리 추출된다. 세 번째 루프는 인덱스

를 1에서

까지 차례로 변경하여 수행된다. 여기서, 1) 서브시스템

에서 구성요소의 총 수

는

의 두 입력 파라메터와 태그 Component를 사용하여 함수 count에 의해 계산되며 2) 해당 서브시스템

은 두 입력 파레미터

과 태그 subSystem으로 함수 extract에 의한 멤버 시스템

으로부터 추출된다. 세 번째 루프 내에서, 본 발명은 모든 구성요소를 탐색하고 해당 모델의 관심 출력을 얻을 수 있다. 특정 구성요소

는

의 두 입력 파라메터와 태그 Component를 사용하여 함수 extract에 의해 서브시스템

에서 추출된다. 추출된 구성요소는 현재 집합 Δ의 두 입력 파라메터와 추출된

로 함수 concat에 의해 집합 Δ에 넣는다. 추출된 성분

을 구하자마자, Markov 모델

는 선택한 구성요소

, IoMTDescription에 있는 모델 설명 및 모델 태그 ctmc을 포함하는 3개의 입력 변수로 함수 generate를 사용하여 생성된다. 생성된 모델의 관심 출력

는 구성요소 모델

및 디폴트 입력 파라메터 IoMTParameters를 포함하는 두개의 입력들로 함수 compute에 의해 계산된다. 구성요소 모델

및 계산된 관심 출력

은 함수 concat에 의해 구성요소 Φ의 집합에 넣는다. 그 후, 구성요소 φ 집합의 항목은 서브시스템 Δ의 집합에 해당 요소로 공급되며, 이는 현재 집합 Δ, Δ에서 대상 구성요소

, 새로 생성된 ψ 및 선택된 구성요소 모델 쌍

및 계산된 관심 출력

을 포함하는 4개의 입력 파라메터로 함수 replace에 의해 구성요소

를 배타적으로 나타낸다. 결과적으로, 세 가지 입력 파라메터로 함수 generate에 의해 서브시스템

의 FT 모델

를 얻을 수 있다.In FIG. 4, without loss of generality, a framework is provided without considering data types of input/output or intermediate parameters/variables that can be used appropriately according to a specific programming language. System architects can use the overall structure of member systems, subsystems and components (IoMTStructure), detailed descriptions (IoMTDescription), and outputs of particular interest

It is assumed to provide sufficient information of the IoMT infrastructure, such as the actual values of the input parameters to compute . An empty set initialization is the member system (

), subsystem (

) and basic components (

) is initially performed on the set of Each of the three main loops is used to discover all member systems, subsystems and components. The first loop is formed with an index l that changes from 1 to n one by one, where the number of member systems n is calculated in advance by two input variables of IoMTStructure and the function count of the corresponding tag memSystem. The second loop is performed using the index i _l which varies by one from 1 to m _l . Here, 1) member system

The total number of subsystems m _l in

is computed by the function cont, which takes two input parameters of and the tag subSystem, and 2) the member system

is pre-extracted by function extract with two input parameters IoMTStructure and tag memSystem. the third loop is the index

from 1

It is performed by changing in turn until Here, 1) subsystem

total number of components in

Is

It is calculated by function count using two input parameters and tag component of 2) corresponding subsystem

is the two input parameters

and member system by function extract with tag subSystem

is extracted from Within the third loop, the present invention can explore all components and obtain the output of interest of the model. specific component

Is

Subsystem by function extract using two input parameters and tag Component of

is extracted from The extracted components are the two input parameters of the current set Δ and the extracted

into the set Δ by the function concat. Extracted Ingredients

Upon finding , the Markov model

is the selected component

, the model description in IoMTDescription, and the model tag ctmc. Output of interest in the generated model

is the component model

and the default input parameter IoMTParameters is computed by the function compute with two inputs. component model

and the computed interest output

is put into the set of components Φ by the function concat. Then, the items of the set of components φ are supplied as corresponding elements in the set of subsystems Δ, which are the target components in the current set Δ, Δ.

, the newly created ψ and the selected component model pair

and the computed interest output

component by function replace with 4 input parameters containing

indicates exclusively. As a result, the subsystem by the function generate with three input parameters

FT model of

can be obtained.

)을 계산할 수 있다. 그런 다음 구성요소의 신뢰도 값은 상위 수준 FT 모델에 입력되어 FT 모델에서 비신뢰성의 확률 계산 방법론을 사용하여 각 서브시스템 및 멤버 시스템에서 관심있는 해당 신뢰도 출력(

)을 계산한다. 모델링에서 최하위 구성요소의 복구(교체)를 고려할 때 각 구성요소의 운영 가용성은 프레임워크의 최하위 수준에서 해당 Markov 모델을 사용하여 계산할 수 있다. 그런 다음 값은 위에서 설명한 것과 유사한 방식으로 FT 모델에서 비가용성의 확률 계산 방법을 사용하여 상위 수준 FT 모델로 전달된다. IoMT 인프라의 보안 속성을 평가하는 경우 공격 강도를 고려한 Markov 모델을 사용하여 사이버 보안 공격이 소프트웨어 구성요소의 신뢰성/가용성에 미치는 영향을 평가할 수 있다. The output of interest calculated and delivered at the lowest level of the Markov chain model up to the full FT model of the IoMT infrastructure is one of the attributes of the reliability and security of the system. For example, if reliability is the output of interest for system evaluation of an IoMT infrastructure, then the probability of never failing after starting work on each component using the lowest-level Markov chain model (

) can be calculated. The component's reliability values are then input into the high-level FT model to generate the corresponding reliability output of interest from each subsystem and member system using the methodology for calculating the probability of unreliability in the FT model.

) is calculated. When modeling considers recovery (replacement) of the lowest-level component, the operational availability of each component can be calculated using the corresponding Markov model at the lowest level of the framework. The value is then passed to the higher-level FT model using a method for calculating the probability of unavailability in the FT model in a similar way to that described above. When evaluating the security properties of an IoMT infrastructure, the impact of a cybersecurity attack on the reliability/availability of software components can be evaluated using a Markov model that considers attack strength.

5 is a flowchart illustrating a method for quantifying dependency and security of an IoMT system based on a cloud-fog-edge continuum using a layer model according to the present invention.

Referring to FIG. 5, the device 100 for quantifying the dependency and security of the IoMT system is placed at the top through the FT system model processing unit 110 and captures the entire IoMT system architecture composed of heterogeneous member systems. FT system model processing including the system model Ψ can be performed (step S510).

The device 100 for quantifying the dependencies and security of the IoMT system includes an FT subsystem model Δ that is placed in the middle through the FT subsystem model processing unit 130 and models the architecture of the subsystem in each of the heterogeneous member systems. FT subsystem model processing may be performed (step S530).

The device 100 for quantifying the dependencies and security of the IoMT system is placed at the bottom through the state-based model processing unit 150 and captures operation behaviors by failure modes and recovery strategies for components in each subsystem. State-based model processing including (Φ) may be performed (step S550).

6 is a diagram showing a hierarchical model.

Referring to Figure 6, the FT model can be composed of three types of different gates, including AND gates, OR gates, and k-out-of-n (KOFN) gates. An AND gate produces a TRUE output if all inputs are TRUE. An OR gate produces a true output if any of its inputs are true. A k-out-of-n (KOFN) gate produces a TRUE output when all k or more of the n inputs are TRUE. KOFN facilitates the evaluation of various combinations of input events. As can be seen in FIG. 6, the entire top-level FT model consists of a three-layer model including:

1) Level 0: The system level consists of FT models that capture the detailed architecture of CFE member systems.

2) Level 1: The subsystem level consists of FT models detailing the component/device architecture within each subsystem.

3) Level 2: The component level consists of CTMC models that capture the operational behavior at the lowest level of IoMT infrastructure components/devices.

When evaluating a particular measure of interest (reliability/availability), the computed output of the CTMC model at the component level is passed to the corresponding component/device in the FT model of that particular subsystem at the subsystem level. In turn, the output of the FT model at the subsystem level is passed from the FT model of a particular member system to the corresponding subsystem at the system level. Finally, the computed output of the FT model representing the member system is the input of the SystemFailure event in the top-level FT model of the IoMT infrastructure. Based on the computed output of the top-level event SystemFailure, you can get the output measurement you are interested in.

The OR gate SystemFailure, whose output is the top-level event in the default IoMT infrastructure, is used to capture the stringent requirements of the IoMT infrastructure design in such a way that any single member system out of the three CFE member systems is considered a total failure of the entire IoMT infrastructure. This top-level FT model is used to evaluate the level of stability/availability of the default IoMT infrastructure. The top-level FT model can be modified according to different architectures of different case studies or operational scenarios of the IoMT infrastructure. These top-level FT models are used to evaluate the reliability/availability solution level of the IoMT infrastructure in the corresponding case studies and scenarios. It is possible to obtain closed analytic solutions for both the FT model and the lowest-order Markov model. For example, a closed solution to the default IoMT infrastructure can be derived based on calculating the probability of unreliability/unavailability for AND, OR, and k-out-of-n gates. The probability calculation of unreliability/availability can be defined as Equation 1 below.

[Equation 1]

는 해당 게이트의 입력 j의 비신뢰성/가용성이다.here,

is the unreliability/availability of input j of that gate.

및

와 같이 입력 j 및 게이트의 출력 결과 각각의 신뢰성/가용성을 명확하게 유추할 수 있다. 디폴트 IoMT 인프라의 경우, 비신뢰성/불가용성의 폐쇄형 표현은 다음의 수학식 2와 같이 얻어질 수 있다.thus,

and

As a result of the input j and the output of the gate, the reliability/availability of each can be clearly inferred. In the case of the default IoMT infrastructure, the closed expression of unreliability/unavailability can be obtained as shown in Equation 2 below.

[Equation 2]

Here, U _C , U _F , and U _E are reliability/availability of member systems.

7 is a diagram showing top-level FT (Fault Tree) models of IoMT infrastructures having different configurations, and FIG. 8 is a diagram showing top-level FT models of IoMT infrastructures according to operating scenarios.

In Figure 7, (a) is the top-level FT model of the default IoMT infrastructure. In (b), two identical clouds A (C _A ) and cloud B (C _B ) in the cloud member system are duplicated, and an AND gate is used to model this assumption. (c) is a case where the same two fog A (F _A ) and fog B (F _B ) of the fog member system are duplicated, and an AND gate is used to model this assumption. (d) is the case where the same two edge A (E _A ) and edge B (E _B ) of the edge member system do not overlap, and failure of all edges is considered to cause complete failure of the entire IoMT infrastructure. An OR gate is used to model . (e) is the case where all member systems are as in (b) to (d), the AND gate is used to capture the redundancy of the double-sized cloud and fog member systems, while the OR gate is used to capture the double-sized edge Used in member systems. Therefore, the unreliability/unavailability of the IoMT infrastructure according to the cases (a) to (e) of FIG. 7 can be derived from Equation 3 below.

[Equation 3]

공식을 사용하여 계산되며 최하위 수준의 CTMC 모델에서 최상위 FT 모델까지 동일한 측정값이 계산된다.reliability/availability

It is calculated using the formula, and the same measurements are calculated from the lowest-level CTMC model to the top-level FT model.

In addition, as shown in FIG. 8, unreliability/unavailability of the IoMT infrastructure may be derived according to operating scenarios. In FIG. 8, (a) is the default IoMT infrastructure, and (b) the fog member system collides and the FT model of the fog member system is removed from the topmost FT model of the IoMT infrastructure. In (c), the cloud member system crashes and the cloud member system's FT model is removed from the top-level FT model of the IoMT infrastructure. In (d), an AND gate is used with the inputs of the cloud and fog FT model in such a way that the collision of cloud and fog and the entire IoMT infrastructure are both mitigated only if they are considered completely failed.

9 is a diagram showing FT models of member systems.

개의 물리적 서버가 있는 것으로 제공된다. 리던던시(Redundancy)는 클라우드에 잘 구현되어 있어 충돌한 서버의 수가 주어진 정수

이상인 경우에만 충분한 컴퓨팅 성능을 제공하는 중단 기간에 클라우드로 간주된다. 이를 캡처하기 위해

-out-of-

게이트를 사용하여 해당 c 클라우드 서버의

하위 모델 입력으로 클라우드 서버 시스템을 모델링한다. 또한, 클라우드 서버와 클라우드 스토리지 간의 연결성을 확보한다는 가정 하에, 실행 중인 클라우드 게이트웨이 전체 수

중 충돌한 클라우드 게이트웨이 수가 특정 수

이상인 경우를 피하기 위해 네트워킹 토폴로지에 관계없이 클라우드가 필요하다. 이러한 이유로

-out-of-

게이트는

개의 클라우드 게이트웨이를 나타내는 하위 모델의 입력과 함께 사용된다. 유사한 가정 하에서 클라우드에서 지속적인 온라인 서비스를 보호하기 위한 또 다른 요구 사항은 항상 충분한 저장 공간을 유지하는 것이다. 따라서

-out-of-

게이트는 한 번에 클라우드 서비스를 호스팅하는 총

개의 클라우드 저장소 중

개 이상의 실패한 클라우드 저장소가 있는 경우 클라우드 저장소 시스템이 고려되는 방식으로 위의 요구 사항을 모델링하는 데 사용된다. 클라우드 서비스를 호스팅하기 위한 충분한 클라우드 스토리지 공간을 제공하지 않는 다운타임 기간에 상주한다. 클라우드 불안정/가용성은 다음 수학식 4로 계산될 수 있다.In FIG. 9, (a) is an FT model of a cloud member system. A cloud member system in which a collision of one of the three main parts of the cloud server, cloud gateway, and cloud storage causes total failure of the cloud member system has strict design requirements. things happen For this reason, an OR gate is used to model this requirement. early in the cloud

It is provided that there are two physical servers. Redundancy is well implemented in the cloud, where the number of crashed servers is given as an integer.

It is considered a cloud during an outage period that provides sufficient computing power only if it is above or below. to capture this

-out-of-

of that c cloud server using gate

Model the cloud server system with sub-model inputs. Also, assuming that connectivity between the cloud server and the cloud storage is secured, the total number of running cloud gateways

number of cloud gateways crashed during

To avoid anomalies, a cloud is required regardless of the networking topology. For this reason

-out-of-

the gate

It is used with the input of a submodel representing cloud gateways. Under similar assumptions, another requirement for securing persistent online services in the cloud is to always have sufficient storage space. thus

-out-of-

Gate is a total hosting cloud service at one time.

of cloud storage

It is used to model the above requirements in such a way that a cloud storage system is considered if there are more than one failed cloud storage. Residing in downtime periods that do not provide sufficient cloud storage space to host cloud services. Cloud instability/availability can be calculated by Equation 4 below.

[Equation 4]

는 클라우드 멤버 시스템의 비신뢰성/비가용성이고,

,

, 및

는 클라우드 서버, 클라우드 게이트웨이 및 클라우드 스토리지의 시스템을 나타내는

-out-of-

,

-out-of-

, 및

-out-of-

게이트의 출력 측정이다.

,

, 및

는 각각 클라우드 서버, 클라우드 게이트웨이 및 클라우드 스토리지를 포함한 서브시스템의 비신뢰성/비가용성 측정이다. 이러한 측정은 서브시스템의 FT 서브시스템 모델에 의해 계산되고 공급된다.here,

is the unreliability/unavailability of the cloud member system,

,

, and

represents a system of cloud servers, cloud gateways, and cloud storage.

-out-of-

,

-out-of-

, and

-out-of-

It is a measure of the output of the gate.

,

, and

is a measure of unreliability/unavailability of subsystems, including cloud servers, cloud gateways, and cloud storage, respectively. These measurements are computed and fed by the subsystem's FT subsystem model.

개의 포그 노드 중 충돌한 포그 노드의 특정

개 이하가 존재해야 한다는 것이다. 따라서

-out-of-

게이트는 위의 서비스 요구 사항을 캡처하는 데 사용된다. 이

-out-of-

게이트의 입력은 포그 노드를 나타내는 모델의 출력이다. 포그 노드는 동일한 아키텍처를 가지고 있다고 가정하므로 일반적으로 포그 노드의 모델을 설명합니다. 도 1에서 볼 수 있듯이, 포그 노드의 전체 다운 상태는 포그 서버, 포그 게이트웨이 또는 포그 저장소의 완전한 오류로 인해 발생한다. 이 요구 사항은 포그 서버, 포그 게이트웨이 및 포그 스토리지 모델의 입력이 있는 OR 게이트로 모델링된다. 차례로, 포그 컴퓨팅 서비스를 호스트하기 위한 엄격한 요구 사항은 총

개의 기존 포그 서버 중 충돌한 포그 서버의 특정

개 이하를 보호하는 것이다. 포그 서버, 포그 게이트웨이 및 포그 스토리지의 모델은 서브시스템 모델에 의해 제공된다.9 (b) is an FT model of the fog member system, the architecture of the fog node is the same, and the service redundancy technology is used to provide sufficient computing resources by securing the number of fog nodes running at one time. Assume that it is installed in The stringent requirements in this matter are for the fog member system to be shot at once.

Particularity of collided fog nodes among fog nodes

That is, there must be less than one. thus

-out-of-

Gates are used to capture the above service requirements. this

-out-of-

The gate's input is the output of the model representing the fog nodes. Fog nodes are assumed to have the same architecture, so we describe the model of a fog node in general. As can be seen in Figure 1, a total down state of a fog node is caused by a complete failure of a fog server, fog gateway or fog repository. This requirement is modeled as an OR gate with inputs from a fog server, fog gateway, and fog storage model. In turn, the stringent requirements for hosting fog computing services are

Part of the crashed fog server among existing fog servers

It is to protect the dog or less. Models of fog servers, fog gateways, and fog storage are provided by subsystem models.

The unreliability/unavailability measure of the fog member system can be calculated by Equation 5 below.

[Equation 5]

는 게이트 포그 노드 τ의 출력 측정값이다. 일반적으로 특정 게이트 포그 노드의

는 다음의 수학식 6으로 계산될 수 있다.here,

is the output measurement of the gate fog node τ. Typically, at a specific gate fog node

Can be calculated by Equation 6 below.

[Equation 6]

는 포그 노드 내의 포그 서버 클러스터를 나타내는 게이트 포그 서버의 출력 측정값이다.

및

는 각각 포그 게이트웨이 및 포그 스토리지 서브시스템을 나타내는 FT 서브시스템 모델의 출력 측정값이다.

는 또한, 다음의 수학식 7을 통해 얻을 수 있다.here,

is the output measurement of the gated fog server representing the cluster of fog servers within the fog node.

and

are the output measurements of the FT subsystem model representing the fog gateway and fog storage subsystem, respectively.

can also be obtained through Equation 7 below.

[Equation 7]

개의 IoMT 노드 중 하나에 장애가 발생하면 전체 엣지 멤버 시스템이 시스템 장애가 발생한 것으로 간주된다. 따라서 모델링에서 위의 요구 사항을 고려하기 위해 IoMT 노드를 나타내는 모델의 입력과 함께 OR 게이트를 메인 게이트로 사용한다. 또한 IoMT 노드의 설계 아키텍처는 서로 동일하다고 가정한다. 따라서 IoMT 노드에 대한 모델링에 대한 설명은 일반적인 경우를 위한 것이다. IoMT 노드의 완전한 장애는 1) IoMT 상태 센서; 2) IoMT 주변 센서; 3) IoMT 무선 통신; 및 4) IoT 게이트웨이 중 하나 또는 장애의 조합으로 인해 발생한다. 이를 모델링하기 위해 해당 서브시스템을 나타내는 모델의 입력과 함께 OR 게이트가 사용된다. IoMT 노드 내 무선 연결은 Markov 모델로 모델링된다. IoMT 상태 및 주변 센서의 경우 특정 개수의 센서, 특히 IoMT 상태 센서 중

개, IoMT 주변 센서 중

개인 경우에만 일부 센서가 한 번에 고장나는 경우를 허용할 수 있다. 또는 그 이상이 한 번에 모두 중단된 경우 해당 센서 시스템이 다운 상태를 경험한 것으로 간주된다. 따라서

-out-of-

게이트 및

-out-of-

게이트는 IoMT 노드에서 IoMT 상태 및 주변 센서 클러스터를 모델링하는 데 사용된다. Figure 9(c) is an FT model of the edge member system. In the edge member system, all IoMT nodes must be in a normal state in order for the edge member system to be considered as UP. Due to the stringent requirements of system architecture design.

If one of the IoMT nodes fails, the entire Edge member system is considered to be system-failed. Therefore, to consider the above requirements in modeling, we use an OR gate as the main gate with the inputs of the model representing IoMT nodes. It is also assumed that the design architectures of the IoMT nodes are identical to each other. Therefore, the description of the modeling of the IoMT node is for the general case. A complete failure of an IoMT node could result in 1) the IoMT health sensor; 2) IoMT ambient sensors; 3) IoMT wireless communication; and 4) one or a combination of failures of the IoT gateway. To model this, an OR gate is used with the inputs of the model representing the subsystem in question. Wireless connectivity within an IoMT node is modeled with a Markov model. For IoMT health and ambient sensors, a certain number of sensors, specifically IoMT health sensors,

of IoMT peripheral sensors

Only in individual cases can it be tolerated that some sensors fail at once. If or more are all down at once, the sensor system in question is considered to have experienced a down condition. thus

-out-of-

gate and

-out-of-

Gates are used to model IoMT state and surrounding sensor clusters at IoMT nodes.

10 is a diagram showing an FT model of a subsystem.

In FIG. 10, (a) is an FT subsystem model of the cloud, and service is interrupted when a failure occurs in hardware (cHW) or software (cSW) of the cloud server. Therefore, an OR gate is used to connect the FT models of cHW and cSW. As a result, the hardware/software of the cloud server goes into a period of downtime when the underlying component crashes. Two OR gates are used to model this behavior. Failures of cloud server hardware include a central processing unit (cCPU), a memory bank (cMEM), a network interface card (cNET), and a cooler unit (cCOO) of the cloud server. Software failures of cloud servers are caused by failures of VMM (cVMM), VM (cVM), and cloud applications/services (cAPP), and presuppose independence between these software components. Also, (d) and (e) of FIG. 10 show FT models of a cloud gateway and a cloud storage subsystem, respectively. It simplifies the investigation of errors in the cloud gateway by using errors in the hardware (cgHW) and software (cgSW) components of the cloud gateway. Therefore, OR gates are used to model hardware/software failures within cloud gateways. On the other hand, cloud storage crashes when the storage disk or storage management software does not work properly.

Based on the modeled FT of the cloud subsystem, an interest metric based on unreliability/unavailability can be calculated as shown in Equation 8 below.

[Equation 8]

10(b) is an FT model of a fog subsystem. Similar to the FT model of a cloud server, a failure of a fog server also occurs due to a failure of a fog hardware/software component. It is also assumed that the hardware architecture of the fog server is similar to that of the cloud server. Failures in fog server hardware are caused by failures in the underlying hardware components, including the fog server's CPU (fCPU), memory bank (fMEM), network interface card (fNET), and cooler component (fCOO). On the other hand, the software of the fog server may fail due to failure of the independently occurring OS (fOS) or fog service/application (fAPP). 10 (f) and (g) show FT models of the gateway and storage subsystem of the fog member system. The assumption about the subsystem is that its fog gateway and fog storage are composed of similar components as the cloud gateway and cloud storage described above. Therefore, the two subsystems are modeled using an OR gate with the input of the basic component CTMC. The FT model of the fog gateway consists of the input CTMC models fgHW and fgSW representing the hardware and software components of the fog gateway, respectively. The input CTMC models of the FT model of fog storage are fSD and fSM, representing the fog storage disk and fog storage management components, respectively.

Unreliability/unavailability of the fog subsystem can be calculated as in Equation 9 below.

[Equation 9]

10(c) is an FT model of the subsystem of the edge, and shows the FT model of the IoMT sensor in the edge member system. The two types of IoMT sensors (IoMT state sensors and IoMT ambient sensors) are assumed to have the same architectural design and mainly consist of hardware (iHW) and software (iSW) components of the IoMT sensor. Also, a failure of an IoMT sensor is considered to be caused by a single failure of either the iHW or the iSW. Therefore, an OR gate is used with the input of the FT model representing the failure of iHW and iSW. IoMT sensor hardware based on the FT model of iHW and iSW Failure of iHW includes failure of at least one of the basic components IoMT sensor's battery (iBAT), IoMT sensing component (iSEN), and analog-to-digital converter (iADC) . the IoMT sensor's microprocessor center unit (iMCU), the IoMT sensor's memory (iMEM), and the IoMT sensor's transceiver (iTRx); An error in one of the IoMT sensor's embedded operating system and sensing applications (iOS and 1508iAPP) will cause an error in the IoMT sensor's software (iSW). The IoMT gateway is modeled using the FT model as shown in (h) of FIG. 10 . This model also uses an OR gate to imply that failures in the IoMT gateway are caused by failures in hardware (igHW) or software (igSW) components of the IoMT gateway. Each of these components is modeled using CTMC.

The unreliability/unavailability of each IoMT sensor and IoMT gateway can be calculated using Equation 10 below.

[Equation 10]

11 is a graph showing reliability of IoMT infrastructure in default parameters, and FIG. 12 is a graph showing reliability analysis of IoMT infrastructure with configuration changes.

Referring to FIGS. 11 and 12, as a result of reliability analysis of the IoMT infrastructure using the layer model proposed in the present invention, the cloud storage and cloud gateway subsystems in FIG. indicate However, looking more closely, the reliability of the cloud gateway over time is lower than that of the cloud storage, which can be seen in the small subplot. This shows that cloud servers are prone to failure over time if recovery operations are not planned in advance. The reliability of cloud server subsystems quickly degrades over time in areas with strong vertical gradients.

11(b) shows the reliability analysis of the subsystem of the fog member system and the entire fog system. Similar to the reliability analysis of the cloud member system in FIG. 11(a), the fog storage and gateway subsystems are also very stable over time, but the fog server subsystem is prone to errors unless recovery is followed. Therefore, the reliability of the fog member system is also reduced. Compared to the cloud member system, the fog member system is slightly more stable because the reliability values of the subsystems are slightly higher, as can be seen by comparing the curves and slopes of each graph.

11(c) shows the reliability analysis result for the edge member system. At the edge layer, the IoMT gateway clearly exhibits the highest reliability in uncertain failures without a planned recovery strategy compared to the reliability values of the IoMT sensors. The IoMT status sensor has higher reliability over time compared to the IoMT ambient sensor, as expected. However, the reliability values of these IoMT devices are not as high as those of gateways and storage subsystems of cloud and fog member systems, as shown in (a) and (b) of FIG. 11 .

In (d) of FIG. 11, the reliability analysis of the individual cloud, fog, and edge member systems described above is synthesized into a common graph, and the effect of the reliability value of the member system on the reliability of the entire IoMT infrastructure is confirmed. Due to the complexity of the entire IoMT infrastructure, which typically consists of multi-level systems, subsystems, and components/devices, and the stringent operational requirements to avoid emergencies, where any failure occurs, system failures, member systems, and overall IoMT infrastructure Reliability values drop vertically over time at specific failures without recovery measures. If we pay attention to the details through the curves in the graph, the fog member system transparently exhibits the highest reliability over the other member systems over time. On the other hand, the cloud member system has the least reliability over time. Moreover, the cloud and edge member systems exhibit distinctly lower reliability over time compared to the fog member system, as seen in the relative distances between the graphs. Because of this, the overall reliability of the IoMT infrastructure drops dramatically over time as it becomes much worse than the reliability of the cloud member systems.

In the design stage of the IoMT infrastructure, considering various system configuration changes, the above detailed reliability analysis of the IoMT infrastructure was expanded with default parameters, and the analysis results are shown in FIG. 12 .

FIG. 12(a) is a graph comparing reliability between cases (a) and (b) of FIG. 7 . When comparing two cloud member systems in FIG. It can be seen that the expansion of the cloud size clearly improves the reliability of the cloud member system itself, as is clearly shown. 12(b) is a graph comparing the reliability between case (a) and case (c) of FIG. 7 , and it can be seen that the expansion of the size of the fog member system clearly improves the reliability of the fog member system. However, the improvement of the fog member system slightly improves the overall reliability of the IoMT infrastructure, as can be seen from the small gap between the graph representing the reconfigured IoMT infrastructure in case (c) and the default infrastructure in case (a) in FIG. 7 . 12(c) is the reliability analysis result of the edge member system and the entire IoMT infrastructure. When the size of the edge member system expands in the reconfigured IoMT infrastructure, due to strict operational requirements caused by errors in the IoMT device at the edge level, The reliability of the edge member system itself and the entire reconfigured IoMT infrastructure is reduced. 12(d) comprehensively shows the reliability analysis results according to cases, and the size expansion of the cloud member system can greatly improve the reliability of the IoMT infrastructure.

The present invention can quantify the reliability of the IoMT infrastructure by developing a comprehensive hierarchical model according to the three-level architecture of the IoMT infrastructure for healthcare monitoring, which is characterized by a continuum of three computing paradigms: cloud, fog, and edge. The layer model consists of the topmost and middle FT models to integrate the various behaviors (failure and recovery) of components within the overall infrastructure member systems, subsystems, and subsystems, resulting in a new approach to reliability evaluation of multi-level architectures of IoMT infrastructures. method can be provided.

Although the above has been described with reference to preferred embodiments of the present invention, those skilled in the art will variously modify and change the present invention within the scope not departing from the spirit and scope of the present invention described in the claims below. You will understand that it can be done.

: FT 시스템 모델 Δ: FT 서브시스템 모델
φ: 상태 기반 모델 100: Apparatus for quantifying dependencies and security of cloud-fog-edge continuum-based IoMT systems using layered models
110: FT system model processing unit
130: FT subsystem model processing unit
150: state-based model processing unit

: FT system model Δ: FT subsystem model
φ: state-based model

Claims (10)

an FT system model processing unit including a Fault Tree (FT) system model (Ψ) disposed at the top and capturing the entire IoMT system architecture composed of heterogeneous member systems;
an FT subsystem model processing unit disposed in the middle and including an FT subsystem model (Δ) modeling the architecture of a subsystem in each of the heterogeneous member systems; and
Cloud-fog using a hierarchical model that includes a state-based model processing unit that is placed at the bottom and includes a state-based model (Φ) that captures operating behaviors by failure modes and recovery strategies for components in each of the subsystems. -A device for quantifying the dependencies and security of Internet of Medical Things (IoMT) systems based on the edge continuum.
The method of claim 1, wherein the FT system model (Ψ) is
Dependence of the Internet of Medical Things (IoMT) system based on the cloud-fog-edge continuum using a hierarchical model, characterized in that it includes a set of FT models representing an FT graph interconnecting the FT models for the heterogeneous member systems, and Security quantifier.
The method of claim 2, wherein each of the FT models is
A cloud-fog-using hierarchical model comprising a subsystem model set for the subsystem, wherein a subsystem model in the subsystem model set corresponds to a graph of an FT model representing an architectural configuration of a member system. A device for quantifying dependencies and security of Internet of Medical Things (IoMT) systems based on the edge continuum.
The method of claim 1, wherein the FT subsystem model (Δ) is
Internet of Medical Things (IoMT) based on cloud-fog-edge continuum using a layer model, characterized in that it includes a set of individual FT models of the subsystem, and each of the individual FT models includes a set of component models System dependencies and security quantifiers.
2. The method of claim 1, wherein the state-based model (Φ) is
Dependency and security quantification of a cloud-fog-edge continuum-based Internet of Medical Things (IoMT) system using a layer model, characterized in that it includes a set of individual Continuous-Time Markov Chain (CTMC) models of the components. Apparatus.
An FT system model processing step including a Fault Tree (FT) system model (Ψ) disposed at the top and capturing the entire IoMT system architecture composed of heterogeneous member systems;
an FT subsystem model processing step including an FT subsystem model (Δ) disposed in the middle and modeling the architecture of a subsystem in each of the heterogeneous member systems; and
A cloud-using hierarchical model including a state-based model processing step including a state-based model (Φ) disposed at the bottom and capturing operation behaviors by failure modes and recovery strategies for components in each of the subsystems. A method for quantifying dependencies and security of Internet of Medical Things (IoMT) systems based on fog-edge continuum.
7. The method of claim 6, wherein the FT system model (Ψ) is
Dependence of the Internet of Medical Things (IoMT) system based on the cloud-fog-edge continuum using a hierarchical model, characterized in that it includes a set of FT models representing an FT graph interconnecting the FT models for the heterogeneous member systems, and How to quantify security.
The method of claim 7, wherein each of the FT models is
A cloud-fog-using hierarchical model comprising a subsystem model set for the subsystem, wherein a subsystem model in the subsystem model set corresponds to a graph of an FT model representing an architectural configuration of a member system. A method for quantifying dependencies and security of Internet of Medical Things (IoMT) systems based on the edge continuum.
7. The method of claim 6, wherein the FT subsystem model (Δ) is
Internet of Medical Things (IoMT) based on cloud-fog-edge continuum using a layer model, characterized in that it includes a set of individual FT models of the subsystem, and each of the individual FT models includes a set of component models A method for quantifying the dependability and security of a system.
7. The method of claim 6, wherein the state-based model (Φ) is
Dependency and security quantification method of the Internet of Medical Things (IoMT) system based on the cloud-fog-edge continuum using a layer model, characterized in that it includes a set of individual Continuous-Time Markov Chain (CTMC) models of the components.

Images