JP2021503639A - 分散型のソフトウェア定義型産業システム - Google Patents
分散型のソフトウェア定義型産業システム Download PDFInfo
- Publication number
- JP2021503639A JP2021503639A JP2020518672A JP2020518672A JP2021503639A JP 2021503639 A JP2021503639 A JP 2021503639A JP 2020518672 A JP2020518672 A JP 2020518672A JP 2020518672 A JP2020518672 A JP 2020518672A JP 2021503639 A JP2021503639 A JP 2021503639A
- Authority
- JP
- Japan
- Prior art keywords
- node
- orchestration
- module
- control
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 claims abstract description 259
- 238000012545 processing Methods 0.000 claims abstract description 69
- 230000004044 response Effects 0.000 claims abstract description 30
- 238000004891 communication Methods 0.000 claims description 80
- 238000011217 control strategy Methods 0.000 claims description 74
- 230000006855 networking Effects 0.000 claims description 27
- 230000000007 visual effect Effects 0.000 claims description 15
- 238000001514 detection method Methods 0.000 claims description 10
- 238000005259 measurement Methods 0.000 claims description 10
- 230000003542 behavioural effect Effects 0.000 claims description 7
- 230000036962 time dependent Effects 0.000 claims description 5
- 230000008569 process Effects 0.000 description 116
- 238000013499 data model Methods 0.000 description 106
- 230000006870 function Effects 0.000 description 88
- 238000004422 calculation algorithm Methods 0.000 description 69
- 238000005516 engineering process Methods 0.000 description 65
- 238000003860 storage Methods 0.000 description 55
- 238000012544 monitoring process Methods 0.000 description 43
- 238000007726 management method Methods 0.000 description 39
- 238000011156 evaluation Methods 0.000 description 30
- 239000010410 layer Substances 0.000 description 28
- 238000013461 design Methods 0.000 description 26
- 230000010354 integration Effects 0.000 description 24
- 239000003795 chemical substances by application Substances 0.000 description 18
- 230000004048 modification Effects 0.000 description 18
- 238000012986 modification Methods 0.000 description 18
- 230000008901 benefit Effects 0.000 description 17
- 238000010586 diagram Methods 0.000 description 17
- 238000004458 analytical method Methods 0.000 description 16
- 230000006399 behavior Effects 0.000 description 16
- 230000035945 sensitivity Effects 0.000 description 16
- 238000004364 calculation method Methods 0.000 description 15
- 238000004519 manufacturing process Methods 0.000 description 14
- 230000007246 mechanism Effects 0.000 description 14
- 238000012360 testing method Methods 0.000 description 14
- 238000011161 development Methods 0.000 description 13
- 230000018109 developmental process Effects 0.000 description 13
- 238000009826 distribution Methods 0.000 description 13
- 230000004913 activation Effects 0.000 description 12
- 230000001419 dependent effect Effects 0.000 description 12
- 238000010801 machine learning Methods 0.000 description 10
- 230000009471 action Effects 0.000 description 9
- 238000005457 optimization Methods 0.000 description 9
- 238000004088 simulation Methods 0.000 description 9
- 230000008859 change Effects 0.000 description 8
- 230000001276 controlling effect Effects 0.000 description 8
- 238000012423 maintenance Methods 0.000 description 8
- 230000003287 optical effect Effects 0.000 description 8
- 230000001413 cellular effect Effects 0.000 description 7
- 238000012512 characterization method Methods 0.000 description 7
- 239000007788 liquid Substances 0.000 description 7
- 238000006243 chemical reaction Methods 0.000 description 6
- 230000036541 health Effects 0.000 description 6
- 241000196324 Embryophyta Species 0.000 description 5
- 238000012790 confirmation Methods 0.000 description 5
- 230000000875 corresponding effect Effects 0.000 description 5
- 238000013507 mapping Methods 0.000 description 5
- 238000012549 training Methods 0.000 description 5
- 238000013459 approach Methods 0.000 description 4
- 238000013468 resource allocation Methods 0.000 description 4
- 238000000926 separation method Methods 0.000 description 4
- 238000012546 transfer Methods 0.000 description 4
- 238000012384 transportation and delivery Methods 0.000 description 4
- 241000282412 Homo Species 0.000 description 3
- 238000007792 addition Methods 0.000 description 3
- 230000032683 aging Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 3
- 238000010276 construction Methods 0.000 description 3
- 238000007405 data analysis Methods 0.000 description 3
- 238000013500 data storage Methods 0.000 description 3
- 238000003066 decision tree Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000005611 electricity Effects 0.000 description 3
- 238000002474 experimental method Methods 0.000 description 3
- 230000006266 hibernation Effects 0.000 description 3
- 230000000670 limiting effect Effects 0.000 description 3
- 230000007774 longterm Effects 0.000 description 3
- 238000003058 natural language processing Methods 0.000 description 3
- 239000003921 oil Substances 0.000 description 3
- 238000013439 planning Methods 0.000 description 3
- 238000004886 process control Methods 0.000 description 3
- 238000011867 re-evaluation Methods 0.000 description 3
- 230000002829 reductive effect Effects 0.000 description 3
- 239000004065 semiconductor Substances 0.000 description 3
- 230000003068 static effect Effects 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 230000001960 triggered effect Effects 0.000 description 3
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 3
- 206010011906 Death Diseases 0.000 description 2
- AYCPARAPKDAOEN-LJQANCHMSA-N N-[(1S)-2-(dimethylamino)-1-phenylethyl]-6,6-dimethyl-3-[(2-methyl-4-thieno[3,2-d]pyrimidinyl)amino]-1,4-dihydropyrrolo[3,4-c]pyrazole-5-carboxamide Chemical compound C1([C@H](NC(=O)N2C(C=3NN=C(NC=4C=5SC=CC=5N=C(C)N=4)C=3C2)(C)C)CN(C)C)=CC=CC=C1 AYCPARAPKDAOEN-LJQANCHMSA-N 0.000 description 2
- 101150071746 Pbsn gene Proteins 0.000 description 2
- 241000233805 Phoenix Species 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 238000013473 artificial intelligence Methods 0.000 description 2
- 238000013475 authorization Methods 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 230000001364 causal effect Effects 0.000 description 2
- QVFWZNCVPCJQOP-UHFFFAOYSA-N chloralodol Chemical compound CC(O)(C)CC(C)OC(O)C(Cl)(Cl)Cl QVFWZNCVPCJQOP-UHFFFAOYSA-N 0.000 description 2
- 230000002596 correlated effect Effects 0.000 description 2
- 239000010779 crude oil Substances 0.000 description 2
- 230000001934 delay Effects 0.000 description 2
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 230000009977 dual effect Effects 0.000 description 2
- 238000005538 encapsulation Methods 0.000 description 2
- 239000004744 fabric Substances 0.000 description 2
- 230000004927 fusion Effects 0.000 description 2
- 230000003116 impacting effect Effects 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 229910052751 metal Inorganic materials 0.000 description 2
- 239000002184 metal Substances 0.000 description 2
- 238000010295 mobile communication Methods 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000011112 process operation Methods 0.000 description 2
- 230000001052 transient effect Effects 0.000 description 2
- 230000007704 transition Effects 0.000 description 2
- 238000013519 translation Methods 0.000 description 2
- 230000035899 viability Effects 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- VCGRFBXVSFAGGA-UHFFFAOYSA-N (1,1-dioxo-1,4-thiazinan-4-yl)-[6-[[3-(4-fluorophenyl)-5-methyl-1,2-oxazol-4-yl]methoxy]pyridin-3-yl]methanone Chemical compound CC=1ON=C(C=2C=CC(F)=CC=2)C=1COC(N=C1)=CC=C1C(=O)N1CCS(=O)(=O)CC1 VCGRFBXVSFAGGA-UHFFFAOYSA-N 0.000 description 1
- MAYZWDRUFKUGGP-VIFPVBQESA-N (3s)-1-[5-tert-butyl-3-[(1-methyltetrazol-5-yl)methyl]triazolo[4,5-d]pyrimidin-7-yl]pyrrolidin-3-ol Chemical compound CN1N=NN=C1CN1C2=NC(C(C)(C)C)=NC(N3C[C@@H](O)CC3)=C2N=N1 MAYZWDRUFKUGGP-VIFPVBQESA-N 0.000 description 1
- MOWXJLUYGFNTAL-DEOSSOPVSA-N (s)-[2-chloro-4-fluoro-5-(7-morpholin-4-ylquinazolin-4-yl)phenyl]-(6-methoxypyridazin-3-yl)methanol Chemical compound N1=NC(OC)=CC=C1[C@@H](O)C1=CC(C=2C3=CC=C(C=C3N=CN=2)N2CCOCC2)=C(F)C=C1Cl MOWXJLUYGFNTAL-DEOSSOPVSA-N 0.000 description 1
- APWRZPQBPCAXFP-UHFFFAOYSA-N 1-(1-oxo-2H-isoquinolin-5-yl)-5-(trifluoromethyl)-N-[2-(trifluoromethyl)pyridin-4-yl]pyrazole-4-carboxamide Chemical compound O=C1NC=CC2=C(C=CC=C12)N1N=CC(=C1C(F)(F)F)C(=O)NC1=CC(=NC=C1)C(F)(F)F APWRZPQBPCAXFP-UHFFFAOYSA-N 0.000 description 1
- ABDDQTDRAHXHOC-QMMMGPOBSA-N 1-[(7s)-5,7-dihydro-4h-thieno[2,3-c]pyran-7-yl]-n-methylmethanamine Chemical compound CNC[C@@H]1OCCC2=C1SC=C2 ABDDQTDRAHXHOC-QMMMGPOBSA-N 0.000 description 1
- HCDMJFOHIXMBOV-UHFFFAOYSA-N 3-(2,6-difluoro-3,5-dimethoxyphenyl)-1-ethyl-8-(morpholin-4-ylmethyl)-4,7-dihydropyrrolo[4,5]pyrido[1,2-d]pyrimidin-2-one Chemical compound C=1C2=C3N(CC)C(=O)N(C=4C(=C(OC)C=C(OC)C=4F)F)CC3=CN=C2NC=1CN1CCOCC1 HCDMJFOHIXMBOV-UHFFFAOYSA-N 0.000 description 1
- BYHQTRFJOGIQAO-GOSISDBHSA-N 3-(4-bromophenyl)-8-[(2R)-2-hydroxypropyl]-1-[(3-methoxyphenyl)methyl]-1,3,8-triazaspiro[4.5]decan-2-one Chemical compound C[C@H](CN1CCC2(CC1)CN(C(=O)N2CC3=CC(=CC=C3)OC)C4=CC=C(C=C4)Br)O BYHQTRFJOGIQAO-GOSISDBHSA-N 0.000 description 1
- WNEODWDFDXWOLU-QHCPKHFHSA-N 3-[3-(hydroxymethyl)-4-[1-methyl-5-[[5-[(2s)-2-methyl-4-(oxetan-3-yl)piperazin-1-yl]pyridin-2-yl]amino]-6-oxopyridin-3-yl]pyridin-2-yl]-7,7-dimethyl-1,2,6,8-tetrahydrocyclopenta[3,4]pyrrolo[3,5-b]pyrazin-4-one Chemical compound C([C@@H](N(CC1)C=2C=NC(NC=3C(N(C)C=C(C=3)C=3C(=C(N4C(C5=CC=6CC(C)(C)CC=6N5CC4)=O)N=CC=3)CO)=O)=CC=2)C)N1C1COC1 WNEODWDFDXWOLU-QHCPKHFHSA-N 0.000 description 1
- KVCQTKNUUQOELD-UHFFFAOYSA-N 4-amino-n-[1-(3-chloro-2-fluoroanilino)-6-methylisoquinolin-5-yl]thieno[3,2-d]pyrimidine-7-carboxamide Chemical compound N=1C=CC2=C(NC(=O)C=3C4=NC=NC(N)=C4SC=3)C(C)=CC=C2C=1NC1=CC=CC(Cl)=C1F KVCQTKNUUQOELD-UHFFFAOYSA-N 0.000 description 1
- IRPVABHDSJVBNZ-RTHVDDQRSA-N 5-[1-(cyclopropylmethyl)-5-[(1R,5S)-3-(oxetan-3-yl)-3-azabicyclo[3.1.0]hexan-6-yl]pyrazol-3-yl]-3-(trifluoromethyl)pyridin-2-amine Chemical compound C1=C(C(F)(F)F)C(N)=NC=C1C1=NN(CC2CC2)C(C2[C@@H]3CN(C[C@@H]32)C2COC2)=C1 IRPVABHDSJVBNZ-RTHVDDQRSA-N 0.000 description 1
- KCBWAFJCKVKYHO-UHFFFAOYSA-N 6-(4-cyclopropyl-6-methoxypyrimidin-5-yl)-1-[[4-[1-propan-2-yl-4-(trifluoromethyl)imidazol-2-yl]phenyl]methyl]pyrazolo[3,4-d]pyrimidine Chemical compound C1(CC1)C1=NC=NC(=C1C1=NC=C2C(=N1)N(N=C2)CC1=CC=C(C=C1)C=1N(C=C(N=1)C(F)(F)F)C(C)C)OC KCBWAFJCKVKYHO-UHFFFAOYSA-N 0.000 description 1
- CYJRNFFLTBEQSQ-UHFFFAOYSA-N 8-(3-methyl-1-benzothiophen-5-yl)-N-(4-methylsulfonylpyridin-3-yl)quinoxalin-6-amine Chemical compound CS(=O)(=O)C1=C(C=NC=C1)NC=1C=C2N=CC=NC2=C(C=1)C=1C=CC2=C(C(=CS2)C)C=1 CYJRNFFLTBEQSQ-UHFFFAOYSA-N 0.000 description 1
- 240000001436 Antirrhinum majus Species 0.000 description 1
- 244000153665 Ficus glomerata Species 0.000 description 1
- 235000012571 Ficus glomerata Nutrition 0.000 description 1
- 238000006424 Flood reaction Methods 0.000 description 1
- WHXSMMKQMYFTQS-UHFFFAOYSA-N Lithium Chemical compound [Li] WHXSMMKQMYFTQS-UHFFFAOYSA-N 0.000 description 1
- HBBGRARXTFLTSG-UHFFFAOYSA-N Lithium ion Chemical compound [Li+] HBBGRARXTFLTSG-UHFFFAOYSA-N 0.000 description 1
- IDRGFNPZDVBSSE-UHFFFAOYSA-N OCCN1CCN(CC1)c1ccc(Nc2ncc3cccc(-c4cccc(NC(=O)C=C)c4)c3n2)c(F)c1F Chemical compound OCCN1CCN(CC1)c1ccc(Nc2ncc3cccc(-c4cccc(NC(=O)C=C)c4)c3n2)c(F)c1F IDRGFNPZDVBSSE-UHFFFAOYSA-N 0.000 description 1
- 208000034972 Sudden Infant Death Diseases 0.000 description 1
- 206010042440 Sudden infant death syndrome Diseases 0.000 description 1
- HCHKCACWOHOZIP-UHFFFAOYSA-N Zinc Chemical compound [Zn] HCHKCACWOHOZIP-UHFFFAOYSA-N 0.000 description 1
- LXRZVMYMQHNYJB-UNXOBOICSA-N [(1R,2S,4R)-4-[[5-[4-[(1R)-7-chloro-1,2,3,4-tetrahydroisoquinolin-1-yl]-5-methylthiophene-2-carbonyl]pyrimidin-4-yl]amino]-2-hydroxycyclopentyl]methyl sulfamate Chemical compound CC1=C(C=C(S1)C(=O)C1=C(N[C@H]2C[C@H](O)[C@@H](COS(N)(=O)=O)C2)N=CN=C1)[C@@H]1NCCC2=C1C=C(Cl)C=C2 LXRZVMYMQHNYJB-UNXOBOICSA-N 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 229910052782 aluminium Inorganic materials 0.000 description 1
- XAGFODPZIPBFFR-UHFFFAOYSA-N aluminium Chemical compound [Al] XAGFODPZIPBFFR-UHFFFAOYSA-N 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000013528 artificial neural network Methods 0.000 description 1
- 230000002238 attenuated effect Effects 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 238000011511 automated evaluation Methods 0.000 description 1
- FFBHFFJDDLITSX-UHFFFAOYSA-N benzyl N-[2-hydroxy-4-(3-oxomorpholin-4-yl)phenyl]carbamate Chemical compound OC1=C(NC(=O)OCC2=CC=CC=C2)C=CC(=C1)N1CCOCC1=O FFBHFFJDDLITSX-UHFFFAOYSA-N 0.000 description 1
- 235000013361 beverage Nutrition 0.000 description 1
- 230000001149 cognitive effect Effects 0.000 description 1
- 238000000205 computational method Methods 0.000 description 1
- 230000010485 coping Effects 0.000 description 1
- 238000012517 data analytics Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000013501 data transformation Methods 0.000 description 1
- 238000013079 data visualisation Methods 0.000 description 1
- 238000000354 decomposition reaction Methods 0.000 description 1
- 238000013135 deep learning Methods 0.000 description 1
- 230000004069 differentiation Effects 0.000 description 1
- 238000009792 diffusion process Methods 0.000 description 1
- 239000003814 drug Substances 0.000 description 1
- 238000005265 energy consumption Methods 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 230000003090 exacerbative effect Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000008713 feedback mechanism Effects 0.000 description 1
- 244000144992 flock Species 0.000 description 1
- 235000013305 food Nutrition 0.000 description 1
- 239000007789 gas Substances 0.000 description 1
- 230000003862 health status Effects 0.000 description 1
- 238000010438 heat treatment Methods 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 239000011229 interlayer Substances 0.000 description 1
- 238000012804 iterative process Methods 0.000 description 1
- 229910052744 lithium Inorganic materials 0.000 description 1
- 229910001416 lithium ion Inorganic materials 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 150000002739 metals Chemical class 0.000 description 1
- 238000005065 mining Methods 0.000 description 1
- 235000019645 odor Nutrition 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 238000003909 pattern recognition Methods 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000003094 perturbing effect Effects 0.000 description 1
- 239000003348 petrochemical agent Substances 0.000 description 1
- 239000003208 petroleum Substances 0.000 description 1
- 230000036316 preload Effects 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 238000004801 process automation Methods 0.000 description 1
- 230000035755 proliferation Effects 0.000 description 1
- 238000013138 pruning Methods 0.000 description 1
- 238000013441 quality evaluation Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000008672 reprogramming Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 238000013515 script Methods 0.000 description 1
- 230000001953 sensory effect Effects 0.000 description 1
- XGVXKJKTISMIOW-ZDUSSCGKSA-N simurosertib Chemical compound N1N=CC(C=2SC=3C(=O)NC(=NC=3C=2)[C@H]2N3CCC(CC3)C2)=C1C XGVXKJKTISMIOW-ZDUSSCGKSA-N 0.000 description 1
- 229910000679 solder Inorganic materials 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000003595 spectral effect Effects 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
- 230000033772 system development Effects 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000000844 transformation Methods 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
- 230000002618 waking effect Effects 0.000 description 1
- 229910052725 zinc Inorganic materials 0.000 description 1
- 239000011701 zinc Substances 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Programme-control systems
- G05B19/02—Programme-control systems electric
- G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
- G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Programme-control systems
- G05B19/02—Programme-control systems electric
- G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
- G05B19/05—Programmable logic controllers, e.g. simulating logic interconnections of signals according to ladder diagrams or function charts
- G05B19/054—Input/output
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Programme-control systems
- G05B19/02—Programme-control systems electric
- G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
- G05B19/41835—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by programme execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2023—Failover techniques
- G06F11/2033—Failover techniques switching over of hardware resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
- H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/084—Configuration by using pre-existing information, e.g. using templates or copying from other elements
- H04L41/0846—Configuration by using pre-existing information, e.g. using templates or copying from other elements based on copy from other elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1044—Group management mechanisms
- H04L67/1048—Departure or maintenance mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1044—Group management mechanisms
- H04L67/1051—Group master selection mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/565—Conversion or adaptation of application format or content
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/10—Plc systems
- G05B2219/11—Plc I-O input output
- G05B2219/1105—I-O
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/10—Plc systems
- G05B2219/12—Plc mp multi processor system
- G05B2219/1214—Real-time communication between plc, Ethernet for configuration, monitor
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/32—Operator till task planning
- G05B2219/32043—Program, information flow
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/33—Director till display
- G05B2219/33112—Configuration software for network
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/805—Real-time
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/82—Solving problems relating to consistency
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/85—Active fault masking without idle spares
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
- Y02P90/80—Management or planning
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Automation & Control Theory (AREA)
- Quality & Reliability (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Mathematical Physics (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Manufacturing & Machinery (AREA)
- Programmable Controllers (AREA)
- Stored Programmes (AREA)
- Hardware Redundancy (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本明細書では、ソフトウェア定義型産業システムを実装するための様々なシステムおよび方法について説明する。例えば、分散型ノードのオーケストレーションシステムは、分散型ノードに実装されたモジュールを含むアプリケーションを実行できる。ノードの故障に応答して、モジュールは交換ノードに再配置され得る。例では、自己記述的制御アプリケーションおよびソフトウェアモジュールが、オーケストレーション可能な分散型システムのコンテキストで提供される。自己記述的制御アプリケーションは、オーケストレータまたは同様の制御デバイスによって実行され、モジュールマニフェストを使用して制御システムアプリケーションを生成し得る。例えば、産業システムのエッジ制御ノードは、ＩＯデータを変換するためのマイクロコントローラ（ＭＣＵ）を含むシステムオンチップを含み得る。システムオンチップは、初期停止状態の中央処理装置（ＣＰＵ）を含み、これは、起動信号に応答して起動状態に変更され得る。
Description
［優先権主張］
本願は、２０１７年１１月１６日に出願された「分散型のソフトウェア定義型産業システム」と題する米国仮特許出願第６２／５８７，２２７号、および２０１７年１２月２９日に出願された「分散型のソフトウェア定義型産業システム」と題する同第６２／６１２，０９２号に基づく優先権の利益を主張し、上記で特定された仮出願は、その全体が参照により本明細書に組み込まれる。
本願は、２０１７年１１月１６日に出願された「分散型のソフトウェア定義型産業システム」と題する米国仮特許出願第６２／５８７，２２７号、および２０１７年１２月２９日に出願された「分散型のソフトウェア定義型産業システム」と題する同第６２／６１２，０９２号に基づく優先権の利益を主張し、上記で特定された仮出願は、その全体が参照により本明細書に組み込まれる。
本明細書で説明する実施形態は、一般に、分散および相互接続デバイスネットワーク内のデータ処理および通信に関し、特に、構成可能なモノのインターネットデバイスおよびデバイスネットワークから提供されるソフトウェア定義型産業システム（ＳＤＩＳ）のオペレーションを定義する技術に関する。
産業システムは、現実世界の計測（例えば、センサ）データをキャプチャし、リアルタイムで応答を作動させつつ、確実かつ安全に動作するように設計されている。このような産業システムを使用するための物理的環境は苛酷であり、温度、振動、および湿度の幅広い変動に遭遇し得る。多くの静的に構成されたＩ／Ｏおよびサブシステムは、完全なユニットの遮断なしに産業システム内で更新する柔軟性に欠けているため、システム設計への小さな変更は実装が難しい場合がある。経時的に、産業システムを適切に動作するために必要な増分変更は、過度に複雑になり、管理が著しく複雑になり得る。さらに、多くの産業制御システムは、動作および設備投資にコストがかかり、多くの制御システムは、最新の情報技術の進歩を利用するように構造的に構築されていない。
ソフトウェア定義型技術（仮想化など）に伴うモノのインターネット（ＩｏＴ）技術と開発により、様々な形態のテレコム、企業およびクラウドシステムの技術が進歩している。リアルタイム仮想化、高可用性、セキュリティ、ソフトウェア定義型システム、およびネットワーキングの技術的進歩により、このようなシステムに改善がもたらされた。ただし、ＩｏＴデバイスは物理的に異種であり得、そのソフトウェアも異種であり得（または経時的に異種性が増大し得る）、このようなデバイスの管理は複雑になる。
産業自動化およびシステムで起こった技術的進歩にもかかわらず、ＩｏＴデバイスおよびＩｏＴフレームワークを利用するための限られた手法が調査された。さらに、新技術のコストが高く、信頼性が証明されていないため、産業システムおよび自動化で新技術を採用することに産業界は躊躇してきた。このような抵抗は、通常、増分変更のみが試行されることを意味する。そしてそれでも、性能を低下させる、またはオンラインにするのに長時間を要した新しい技術の例は数多くある。その結果、ＩｏＴ技術とソフトウェア定義型技術の大規模な配置は、産業環境にうまく適応されていない。
必ずしも一定の縮尺で描かれていない図面において、同様の数字は、異なる図において類似のコンポーネントを説明し得る。異なる文字の接尾辞を有する同様の数字は、類似のコンポーネントの異なるインスタンスを表し得る。いくつかの実施形態は、添付の図面の図において、限定ではなく例として示される。
以下の説明では、方法、構成、および関連する装置が、ソフトウェア定義型産業サービス（ＳＤＩＳ）配置の構成、オペレーション、および適合のために開示されている。特に、次のＳＤＩＳ配置は、このような配置の派生アーキテクチャまたはソリューションインスタンスと共に、最新の動作アーキテクチャに基づく産業システムの機能を含む。例えば、このようなアーキテクチャおよびインスタンスは、制御システムまたは監視システム内のエッジ制御デバイスおよび制御メッセージバスの機能を実装する仮想化制御サーバシステムを含み得る。このようなアーキテクチャおよびインスタンスは、様々な形のＩｏＴデバイスとオペレーションを含むＩｏＴネットワークの態様とさらに統合できる。
本明細書で説明する処理技術および構成は、様々なタイプのＳＤＩＳアーキテクチャ内のオペレーション、データ、および処理を管理するための様々な手法を含む。次の手法の概要は、次の段落で提供されている。特定の実装例とユースケースへのさらなる参照は、以下で説明されている。
例では、ＳＤＩＳアーキテクチャのアプリケーション、デバイス、またはセンサに動的な一連の機能を提供するために、動的データモデルが確立される。このような動的データモデルは、本質的にデータ駆動型であり得、一般的に開発中に確立される静的に定義されたデータモデルと対照的であり得る。例えば、動的データモデルはセンサの集合であるデバイスで表すことができ、デバイスは変化する要素（バッテリーや計算可用性など）に基づいて様々な出力センサでデバイス自体を表すことができる。この動的データモデルは、ＩｏＴの様々なシステムおよびデータを適応可能にしながら使用できるようにする上で重要な役割を果たし得る。動的データモデルの機能により、デバイスがランタイムにデバイスのコンポーネントを修正および拡張し、またそのコンポーネントのサブセットに戻る能力が提供される。さらに、動的データモデルは、動的メタデータ、複雑な値の表現（バイナリのオン／オフステータスの代わりにタグの確率論的推定値の提供を含む）によって具現化できる。
また、例では、分散型リソースプール全体で実行される複数の依存型アプリケーション（例えば、機能ブロック）の全体的なオーケストレーションおよび管理をサポートするために、ＳＤＩＳアーキテクチャで構成を確立できる。オーケストレーションは、拡張されたオーケストレータロジックルールセットにアプリケーション固有の追加の依存性を含めることにより、分散型システム構成の組み込み制御戦略レベルで可能になり得る。ネットワーク帯域幅の動的発見、リソース容量および現在の状態の評価、履歴情報および制御アプリケーションの制約などの情報を通じて、様々なマルチ階層の最適化および予測方法を実行して、高度なオーケストレーションシナリオを実現できる。このような機能により、リアルタイムイベントに対して予測を利用して、オーケストレーションイベントへの反応をステージングし、より広範な制御戦略のオンラインステータスを維持することもできる。さらに、このようなオーケストレーションのリアルタイムの最適化と組み合わせた予測および制約の管理により、高度なレベルの組み込みインフラストラクチャの復元力および機能性が有効になり得る。
また、例では、機能のオーケストレーションは、既存の形式のブラウンフィールド環境（既存のデバイス構成アーキテクチャを指すこのような「ブラウンフィールド」デバイスを使用）に拡張できる。このようなレガシー設定でのオーケストレーションは、次の方法で可能にできる。アプリケーションとデバイスレベルの両方でシムを使用して、認識されていないアプリケーションコンポーネントおよびレガシーデバイスのオーケストレーションをサポートする。階層を使用してスケールデバイスおよびレガシーデバイスをサポートする。自己監視を適応して、様々なデバイスの異質性、リソース使用率、スケール、および組み込みの自己依存性を管理する。ＳＤＩＳアーキテクチャ内でのこのようなオーケストレーション技術のアプリケーションを使用して、アーキテクチャの拡張性を向上させ、様々な形式のデバイス、システム、および産業を含めることができる。さらに、このようなオーケストレーション技術により、顧客が既存の技術プラットフォームに既に多大な投資をしている状況で技術を適用できる。
また、例では、機能のオーケストレーションが、顧客がハードウェア配置の差別化機能を活用できる重要な制御点として利用され得る。このようなオーケストレーションは、自己記述的モジュールによって有効化され得、自己記述的モジュールは、オーケストレーション可能な分散型システムのコンテキストで自己記述的制御アプリケーションおよびソフトウェアモジュールを使用するための配置可能なメカニズムを提供する。このような自己記述的モジュールにより、実装間のトレードオフが許容され、プラットフォームの機能が使用可能な場合はその機能をカスタマが効果的に利用でき、一方、機能がない場合は代替機能を利用できるようになる。次の例は、これらのトレードオフを自動的に評価するように適合されたＳＤＩＳアーキテクチャでの実装を含んでいるため、産業のユースケースおよび配置の機能をより効果的に開発できる。
また、例では、本明細書で説明されるシステムおよび方法が、コントローラとフィールドデバイスとの「任意から任意」の関係を可能にする多層フィールドデバイス冗長バスを含む。コントローラとＩＯの分離により、単純なフェイルオーバーと冗長性が可能になる。コントローラが故障した場合に任意のコントローラが任意のフィールドデバイスにアクセスできるようにすることで、システムの信頼性および存続性の向上が実現される。ＰＬＣの重い負担の代わりに、わずかな追加投資に基づいて新しいフィールドデバイスを追加するなどによる、システムコストの削減も利点になり得る。
また、例では、本明細書で説明されるシステムおよび方法は、スマート機械学習手法を使用してアラームを管理し得る。本明細書で説明されるシステムおよび方法は、以下を含み得る。異常を検出するためにアラームをトリガーし得るデータを特徴付ける。データの類似性または一般的な因果関係のいずれかを使用してアラームをクラスタ化して、その結果、アラームの過多およびアラーム疲れを抑制するための１つのバンドルとして提示されるようにする。または将来のそれらの動作を自動化するために、アラームに対する人間の反応を理解する。
また、例では、次の８つの段階のプロセスを通じて、ミッションクリティカルな環境での新しい閉ループ作業負荷の自動作成を管理するために、順次厳密なポリシーフレームワークおよび一連の方法を本明細書に示す。プロセスに対する新しいアルゴリズムの品質および感度の評価。動作制約境界の自動化された設定。既存のプロセスに対する新しいアルゴリズムの自動化された安全性評価。幅広いプロセスのための自動化された価値評価。制御環境での配置の実現可能性に関する自動化されたシステム評価。新しいアプリケーション制御戦略の物理的な配置および監視。ライフサイクル管理システムへの統合。およびサポート終了処理への統合。
また、例では、本明細書で説明されるシステムおよび方法は、産業制御システムのエッジでの計算機能の過剰または不十分な提供という問題に対処する。計算リソースを過剰に提供すると、お金、電気エネルギー、および熱エネルギーが浪費される。計算リソースの提供が不足すると、信頼性および制御戦略を実行する能力が犠牲になる。提案されたソリューションにより、性能要件データを有するエンドユーザは、制御環境で提供される計算の量を「適切な」サイズにし得る。さらに、提供された計算機能は静的ではなく、要件の変化に応じて制御システムのニーズを満たすように適合され得る。本明細書で説明する手法では、制御戦略のＣＰＵ性能のニーズを理解する集中型オーケストレーションシステムによって、エッジ制御ノードで初期の休止状態から高性能ＣＰＵを起動できる。
また、例では、追加のモジュール相互接続技術が開示される。オーケストレーションシステムでは、通常、アプリケーションはトポロジを介して相互接続された一連のモジュールとして定義される。これらのモジュールは、異なるロジックノードに配置される。各ロジックノードは物理ノードに対応し得るが、マッピングは１：１である必要はない。リソース要件が満たされている限り、複数のロジックノードが１つの物理ノードに潜在的にマッピングされることができ、複数のモジュールが同じ物理環境に配置され得る。例では、ソリューションは、アプリケーションの通信パターンに基づくモジュールの自動バックアップノードを作成し得る。同じ層上のノードのコレクションによって作成されたピアツーピアネットワークが、バックアップのステータスをネゴシエートし得る。このノードのコミュニティは、他のアプリケーションに大きな影響を与えることなく、ノード間でバックアップを交換できる。
他の例は、以下の図面およびテキストの開示から明らかになる。
［産業自動化システムの概要］
［産業自動化システムの概要］
効果的な産業自動化システムの設計および実装には、多くの技術的課題がある。多くの場合、産業プラントのライフサイクルは、プラントを稼働させる技術のライフサイクルをはるかに上回っているため、技術の管理およびメンテナンスのコストを管理することは非常に困難である。例では、ＳＤＩＳ配置は、次の手法によるリソース抽象化を通じて、産業システムのソフトウェアおよびハードウェアリソースの動的構成（および再構成）に適合され得る。このようなリソースの抽象化により、産業システムをサービスから外すことなく構成を更新する柔軟性が提供される。このようなリソースの抽象化により、経時的に機能が改善された産業システムを更新するための柔軟性も提供される。
現在開示されているＳＤＩＳ手法でのオープンアーキテクチャおよびソフトウェアとハードウェアとの間の抽象化されたリンクの使用は、ベンダーが特定のベンダーアプリケーションの機能および実装に集中できるようにしつつ、これらおよびその他の技術的利点を提供する。開示されているオープンアーキテクチャは、イノベーションを促進し、ハードウェアの交換コストを削減し、ハードウェアが陳腐化するリスクを排除する。開示されているオープンアーキテクチャにより、ハードウェアの信頼のルート、署名付きアプリケーション、および包括的なセキュリティ管理などを使用して、セキュリティをＳＤＩＳの本質的な部分として実装できる。このような構成により、固有のセキュリティと、経時的に機能を簡単に統合する機能とを備えた、簡略化された制御システムが可能になる。これらの技術的改善とオープンアーキテクチャの機能および標準実装の組み合わせにより、ＳＤＩＳ内の産業制御の迅速な統合が可能になる。
オープングループのオープンプロセス自動化フォーラムなどのいくつかの既存の手法は、食品および飲料、鉱業および金属、石油およびガス、石油化学、製薬、パルプおよび紙、およびユーティリティなどの業界を対象とした、産業自動化向けの標準に基づくオープンで相互運用可能なプロセス制御アーキテクチャ機能の開発を開始した。ＳＤＩＳの現在の構成および機能、それに付随するサブシステムおよび技術は、この標準または産業自動化とシステム配置の取り組みにおける類似の手法を使用して統合され得る。さらに、ＳＤＩＳおよび付随するサブシステムの現在の構成および機能は、これらまたは他の産業で利用され得る。したがって、以下の実装の変動および変更は明らかである。
図１Ａは、ＳＤＩＳ動作アーキテクチャの第１の例示的な構成を示す。示されるように、制御メッセージバス１１２は、動作ツール１２０、制御サーバ（ＣＳ）ノード１３０Ａ、エッジ制御ノード（ＥＣＮ）システム１５０、インテリジェントＩ／Ｏコントローラシステム１６５、ベーシックＩ／Ｏコントローラシステム１６０、ゲートウェイシステム１７０、および制御ステーション１１５を含むこのようなコンポーネントとアーキテクチャの様々なコンポーネントを接続するために使用される。様々なフィールドデバイス（１５１、１６１、１６６、１７１）がそれぞれのシステム（１５０、１６０、１６５、１７０）に接続されている。この動作アーキテクチャのユースケースおよび構成の例のいくつかについては、以下でさらに説明する。
例では、動作ツール１２０は、手順開発ツール、ヒストリアンツール、ヒューマンマシンインタフェース（ＨＭＩ）開発、制御、およびオペレーションツールの態様を含み得る。動作ツール１２０の様々な態様は、（図２Ａにさらに示されるように）制御サーバノード１３０Ａで動作するそれぞれの仮想マシン１３１Ａで実装され得る。
例では、制御サーバノード１３０Ａは、ハイパーバイザ層１３２Ａを介して連携し、ホストオペレーティングシステム１３３Ａおよびコンピュータハードウェアアーキテクチャ１３４Ａの機能で動作する、様々な仮想マシン１３１Ａの態様を含み得る。制御サーバノード１３０Ａは、マシンオーケストレーションと動作アプリケーションオーケストレーションの両方を含む、オーケストレーション１３５Ａの様々な態様を実装するために使用され得る。制御サーバノード１３０Ａのさらなる詳細な説明は、以下の図２Ａを参照して以下に提供される。
例では、ＥＣＮシステム１５０は、特定のハードウェア（例えば、ｘ８６またはＡＲＭハードウェア実装）で動作するＥＣＮのＩ／Ｏコントローラ（例えば、ノード１５０Ａ、１５０Ｂ）からのオーケストレーション（例えば、オーケストレーション実装）の様々な態様を含み得る。ＥＣＮシステム１５０のさらに詳細な例および様々な接続されたデバイス（例えば、フィールドデバイス１５１Ａ、１５１Ｂ）のオーケストレーションにおけるＥＣＮシステム１５０の役割は、図２Ｂを参照して以下に提供される。
例では、インテリジェントＩ／Ｏシステム１６５は、様々なデバイス（例えば、フィールドデバイス１６６Ａ、１６６Ｂ）の制御またはアクセスに使用される、インテリジェントＩ／Ｏコントローラ（例えば、コントローラ１６５Ａ、１６５Ｂ）および付随するオペレーティングシステムからの産業制御の様々な構成可能な態様を含み得る。また、例では、ベーシックＩ／Ｏシステム１６０は、様々なデバイス（例えば、フィールドデバイス１６１Ａ、１６１Ｂ）の制御またはアクセスに使用される、ベーシックＩ／Ｏコントローラ（例えば、コントローラ１６０Ａ、１６０Ｂ）および付随するオペレーティングシステムからの産業制御の様々な動作態様を含み得る。
例では、ゲートウェイシステム１７０は、様々なデバイス（例えば、フィールドデバイス１７１Ａ、１７１Ｂ）の制御またはアクセスに使用される、ゲートウェイ（例えば、ゲートウェイ１７０Ａ、１７０Ｂ）からの他のデバイスネットワークまたは配置への接続のための様々な構成可能な態様を含み得る。様々なデバイス内での、センサ（「Ｓ」）およびアクチュエータ（「Ａ」）コンポーネントの役割は、フィールドデバイス全体（例えば、フィールドデバイス１５１Ａ、１５１Ｂ、１６１Ａ、１６１Ｂ、１６６Ａ、１６６Ｂ、１７１Ａ、１７１Ｂ）にラベル付けされている。デバイスおよびコンポーネントの追加の数とタイプもまた、様々なシステム１５０、１６０、１６５、１７０に結合され得ることが理解されよう。
図１Ａに示されている動作アーキテクチャは、ＨＷ／ＳＷモジュール性、ＳＷの移植性、相互運用性、アプリケーションの拡張性および計算の拡張性など、従来の企業アーキテクチャで見られる同じ属性の多くを有効にするように構成されている。これに加えて、このアーキテクチャに導入された新しいインフラストラクチャフレームワークコンポーネントは、特にＣＳおよびＥＣＮシステムの実装において、本明細書で説明するＳＤＩＳ技術の集中および分散の両方の概念をサポートするように配置され得る。
例えば、ＥＣＮのＩ／Ｏコントローラ（例えば、ＥＣＮノード１５０Ａ、１５０Ｂ）の使用は、過去５０年間にわたって進化してきた現在のＤＣＳ（分散型制御システム）およびＰＬＣ（プログラマブルロジックコントローラ）制御システムからの、著しいアーキテクチャの逸脱である。ＡＮＳＩ／ＩＳＡ−９５自動化インタフェーススタックのこのミッションクリティカルな部分におけるアーキテクチャいかなる進歩も、プロセス制御の厳格で回復力のある要件に準拠する必要がある。本明細書で説明するＳＤＩＳアーキテクチャにより、ＥＣＮシステムはこれらの厳しい動作要件を維持するだけでなく、オープンで相互運用可能なままでもあり得、進行中の技術進歩により、産業用途でこれらのシステムを安全、確実、セキュアかつ迅速に導入または更新するのが可能になる。現在のＳＤＩＳアーキテクチャは、動作および制御スタック全体で、より広いエコシステム参加、イノベーション、および生産のカスタマイズを可能にする。例えば、ＥＣＮシステムには、基本制御システムの構築ブロックとして機能する制御分解が提供され、制御機能のカスタマイズを増幅し、様々なユースケースのプロセスの柔軟性を高めることができる。
図１Ｂは、ＳＤＩＳ動作アーキテクチャの第２の例示的な構成を示す。図１Ａに示されるのと類似の方法で、図１Ｂの構成は、動作アーキテクチャの様々なコンポーネントを接続するために使用される制御メッセージバス１１２を示し、クラウドコンポーネント（制御サーバとして動作するリアルタイムのアドバンスドコンピューティングシステム１３０Ｂ、およびクラウドコンピューティングサービス１８０）エッジコンポーネント（構成エッジコンピューティングノード１９１Ａ、１９１Ｂ、１９１Ｃ、第１エッジコンピューティングプラットフォーム１９３、および第２エッジコンピューティングプラットフォーム１９５を備えたエッジエコシステム１９０）を含むこのようなコンポーネント、および制御ステーション１１５を備える。センサとアクチュエータを備えた様々なフィールドデバイス（１９２、１９４）がそれぞれのエッジコンピューティングノード（エッジエコシステム１９０およびエッジコンピューティングプラットフォーム１９３、１９５）に接続されている。上述の動作目標および特徴は、図１Ｂの構成にも適用可能である。
図１Ａに導入されたＳＤＩＳ動作アーキテクチャのさらなる拡張として、図１Ｂの構成は、様々なクラウドおよびエッジコンポーネントにわたるコントローラおよびサーバのオペレーションが、それぞれの仮想マシンを通じて仮想化され、それぞれのコンテナで配置され、それぞれのアプリケーションで配置され、またはそれらの任意の組み合わせであるシナリオを示す。その結果、図１ＢのＳＤＩＳ動作アーキテクチャは、様々なハードウェア設定（ＡＲＭおよびｘ８６ハードウェアアーキテクチャの両方を含む）への再構成可能で柔軟な配置を可能にする。リアルタイムアドバンスドコンピューティングシステム１３０Ｂのさらなる内訳が図３Ａに示されている。クラウドコンピューティングサービスノード１８０およびエッジコンピューティングノード１９３のさらなる内訳が、それぞれ図３Ｂおよび図３Ｃで説明される。
ＳＤＩＳアーキテクチャの別の態様は、リアルタイム通信の使用を含み得る。サービスバスファブリック１１０上でホストされる制御メッセージバス１１２は、複数のレベルでのインターネットワーキング収束を可能にするために利用され得る。例えば、制御メッセージバス１１２は、イーサネット（登録商標）に基づく時間依存のネットワーキング（ＴＳＮ）オープン標準（例えば、ＩＥＥＥ８０２．１ＴＳＮタスクグループ）を介するなど、時間依存のイーサネットトランスポートの使用を可能にし得る。さらに、制御メッセージバス１１２の使用は、クラウドサーバラックレベルで、およびエッジノードの大規模なネットワーク化またはシャーシにわたって、より大きな性能およびスケールを可能にし得る。
ＳＤＩＳアーキテクチャでは、リアルタイムサービスは、イーサネットＴＳＮを介するなど、制御メッセージバス１１２を介してリアルタイム物理トランスポートの上で動作し得る。制御メッセージバス１１２は、ＩｏＴ設定（例えば、オープンプラットフォームコミュニケーション統合アーキテクチャ（ＯＰＣ−ＵＡ）、オブジェクト管理グループデータ配信サービス（ＤＤＳ）、ＯｐｅｎＤＸＬ、オープンコネクティビティファンデーション（ＯＣＦ）などの標準を使用）における既存のミドルウェアまたは通信スタックの異質性に対処するように適合されて、シームレスなデバイス間接続を可能にして、ＩｏＴ配置の新たな実装に対処し得る。
例では、ＳＤＩＳアーキテクチャのオーケストレーション管理は、制御サーバ（ＣＳ）設計によって実装され得る。図２Ａは、ＳＤＩＳ動作アーキテクチャ（例えば、図１Ａを参照して上述した動作アーキテクチャ）内の制御サーバサブシステム（例えば、ＣＳノード１３０Ａを実装する）の構成を示す。具体的には、図２Ａは、ＣＳノード１３０Ａおよびそのコンポーネント仮想マシン１３１Ａ、ハイパーバイザ１３２Ａ、ホストオペレーティングシステム１３３Ａ、およびハードウェアアーキテクチャ１３４Ａのさらなる図を提供し、図示のように、ＣＳノード１３０Ａは単一ノードとして示されているが、これらのノード全体に分散された多くの仮想マシンを備えた２つまたはそれより多くのノードを含み得る。
例では、ＣＳノード１３０Ａは、マシンおよびオペレーションアプリケーションオーケストレーションから促進されるオーケストレーション１３５Ａを含み得る。マシンオーケストレーションは、プラットフォーム管理を実装するためのデータベースなどのマシンライブラリ１３６を使用して定義され得る。オペレーションアプリケーションオーケストレーションは、制御機能ライブラリ１４２および動作アプリケーションライブラリ１４４を使用して定義され得る。例えば、制御標準設計１４１および統合された（および安全な）アプリケーション開発プロセス１４３を使用して、ライブラリ１４２、１４４を定義し得る。
例では、ＣＳノード１３０Ａは、仮想化環境でＩＳＡレベルのＬ１〜Ｌ３アプリケーションをホストするように設計されている。これは、ハイパーバイザ１３２Ａの上で仮想マシン（ＶＭ）１３１Ａを実行することにより実現され、各ＶＭが将来型空中能力環境（Ｆｕｔｕｒｅ Ａｉｒｂｏｒｎｅ Ｃａｐａｂｉｌｉｔｙ Ｅｎｖｉｒｏｎｍｅｎｔ）（ＦＡＣＥ）準拠のスタックとアプリケーション、またはヒューマンマシンインタフェース（ＨＭＩ）、ヒストリアン、オペレーションツールなどの非ＦＡＣＥアプリケーションをカプセル化することで実現できる。例では、ＦＡＣＥ準拠のＶＭは、ＶＭにカプセル化されたＦＡＣＥスタック全体（オペレーティングシステム、ＦＡＣＥセグメント、および１つまたは複数のポータブルコンポーネント）を提供し得る。カプセル化とは、各ＶＭがＬｉｎｕｘ（登録商標）、ＶｘＷｏｒｋｓ、またはＷｉｎｄｏｗｓ（登録商標）などの異なるオペレーティングシステムが実行され得る場合でも、ハイパーバイザ１３２Ａによってホストおよび他のＶＭから分離された独自の仮想リソース（計算、ストレージ、メモリ、仮想ネットワーク、ＱｏＳ、セキュリティポリシーなど）を各ＶＭが有し得ることを意味する。
仮想化と堅牢性の利点を最大化するために、ポータブルコンポーネントの関連グループが、複数のＦＡＣＥ準拠のＶＭを使用してＦＡＣＥ準拠のＶＭにグループ化され得る。この手法を使用すると、ＣＳハードウェア全体に作業負荷が分散され、コンポーネントのグループ（ネットワークなど）に固有のリソースが分離される一方で、アプリケーションは、依然としてネットワークを経由してＥＣＮなどの他の仮想化デバイスおよび物理デバイスと通信できる。ＶＭ全体にＦＡＣＥポータブルコンポーネントを分散すると、無関係なコンポーネントを相互に分離することでセキュリティが向上し、故障に対する堅牢性が提供され、機能の独立した更新が可能になり、統合が容易になり、個々のベンダーが完全に機能するＶＭをシステムに提供できるようになる。
さらなる例では、レイヤ２のコンポーネントを別々のＶＭ（またはＶＭのグループ）内のレイヤ３のコンポーネントから分離してレイヤ間の分離を提供し、異なるネットワーク接続、セキュリティ制御、および監視をレイヤ間に実装できるようになり得る。ポータブルコンポーネントをグループ化すると、統合に利点がもたらされ得、複数のベンダーソリューションを簡単に組み合わせて、複数の仮想マシンを実行し、それらの間のネットワークを構成できるようになる。また、さらなる例では、Ｗｉｎｄｏｗｓ、Ｌｉｎｕｘ、およびその他のＩｎｔｅｌアーキテクチャ互換のオペレーティングシステム（例えば、ＶｘＷｏｒｋｓリアルタイムオペレーティングシステム）などの追加のオペレーティングシステムは、各々仮想マシンとして配置され得る。ＣＳノード１３０Ａ内の現在開示されているＶＭの他の構成も、他の技術的利点を可能にし得る。
例では、クラウドインフラストラクチャプラットフォームが、Ｌｉｎｕｘ、ＫＶＭ、ＯｐｅｎＳｔａｃｋ、およびＣｅｐｈなどのオープンソース標準および実装を使用して適合されたリアルタイムアドバンストコンピューティングシステムなど、ＣＳノード１３０Ａで利用され得る。例えば、クラウドインフラストラクチャプラットフォームは、プラットフォームおよび作業負荷の高可用性、継続的な２４時間３６５日のオペレーション、確定性／レイテンシ、高性能、リアルタイムの仮想化、拡張性、アップグレード性、およびセキュリティなどの重要なインフラストラクチャ要件に対応するように適合され得る。クラウドインフラストラクチャプラットフォームは、ソフトウェア定義型産業自動化固有の重要なインフラストラクチャ要件を満たすように適合され得る。
図２Ｂは、ＳＤＩＳ動作アーキテクチャ（例えば、図１Ａを参照して上述した動作アーキテクチャ）内の分散エッジ制御ノード（ＥＣＮ）サブシステムの構成例を示す。例では、ＥＣＮノード１５０Ａ、１５０ＢはＩＳＡ−９５レベル１／レベル２に常駐し、基本的な基本ＨＷ／ＳＷ構築ブロックとして配置される。
例では、ＥＣＮノード１５０Ａ、１５０Ｂは、センサまたはアクチュエータあるいはスマートデバイス（例えば、ＥＣＮキャビネットの外部に配置された）を介して単一フィールドバスデバイスへの単一入力または出力をサポートする。ＥＣＮデバイスアーキテクチャは、既存の独自のＤＣＳシステムによる配線、アップグレード、および耐故障性の制限に対処する分散型制御システムの開放性および軟性を拡張するＥＣＮキャビネットまたはラックシステムを通じて拡張され得る。例では、ＥＣＮアーキテクチャは、ＦＡＣＥ準拠のスタックがセグメントまたはグループソフトウェアモジュールとして実装された標準的なＰＯＳＩＸ ＯＳで動作する。以下の例では、これらのソフトウェアモジュールを配置するための様々な手法が参照される。
ＥＣＮノード１５０Ａ、１５０Ｂは、オーケストレーションおよびサービス（図６について以下に示されるオーケストレーションなど）の態様のための様々なソフトウェア定義型マシンをサポートし得る。例では、ＥＣＮノード１５０Ａ、１５０Ｂは、インテル（登録商標）のソフトウェア・ガード・エクステンションズ（Ｉｎｔｅｌ（登録商標）Ｓｏｆｔｗａｒｅ Ｇｕａｒｄ ｅＸｔｅｎｓｉｏｎｓ）：ＳＧＸ）、ダイナミックアプリケーションローダ（Ｄｙｎａｍｉｃ Ａｐｐｌｉｃａｔｉｏｎ Ｌｏａｄｅｒ：ＤＡＬ）、セキュアＶＭＭ環境、信頼できるコンピューティング標準のトラステッドプラットフォームモジュール（ＴＰＭ）などの、様々なハードウェアセキュリティ機能および信頼できる実行環境と統合できる。さらなる例では、セキュアブートが、インテル（登録商標）のコンバージドセキュリティ（Ｉｎｔｅｌ（登録商標） Ｃｏｎｖｅｒｇｅｄ Ｓｅｃｕｒｉｔｙ）および管理エンジン（Ｍａｎａｇｅａｂｉｌｉｔｙ Ｅｎｇｉｎｅ）（ＣＳＭＥ）やプラットフォームトラスト技術（Ｐｌａｔｆｏｒｍ Ｔｒｕｓｔ Ｔｅｃｈｎｏｌｏｇｙ）：ＰＴＴ）などの保護されたハードウェア暗号化エンジン内でアクセスされる融合および保護された重要なマテリアルで有効化できる。さらに、ＡＥＳ暗号化およびＳＨＡ計算のための特別なハードウェア命令を使用して、暗号化機能をより安全にし得る。インテル（登録商標）の拡張プライバシーＩＤ（Ｉｎｔｅｌ（登録商標） Ｅｎｈａｎｃｅｄ Ｐｒｉｖａｃｙ ＩＤ）（ＥＰＩＤ）などの他の形式のセキュリティが、好ましいデバイス識別キーとして業界全体で採用されている場合がある。これは、デバイスの安全なゼロタッチオンボーディング用の自動化されたデバイス登録（例えば、インテルのセキュアデバイスオンボーディング（Ｉｎｔｅｌ Ｓｅｃｕｒｅ Ｄｅｖｉｃｅ Ｏｎｂｏａｒｄｉｎｇ（ＳＤＯ））技術を通じて可能になり得る。さらなる例では、ＥＣＮノード１５０Ａ、１５０ＢおよびＳＤＩＳアーキテクチャの他のサブシステムは、これらまたは他のセキュリティ手法と相互運用可能であり得る。
図３Ａは、図１ＢのＳＤＩＳ動作アーキテクチャ内に配置可能なリアルタイムのアドバンスドコンピューティングシステム１３０Ｂのより詳細な構成を示す。具体的には、図３Ａの構成は、ハイパーバイザ層１３２Ｂ上で動作する、仮想マシン、コンテナ、およびアプリケーションの異なる配置タイプを含み得るそれぞれの仮想マシン１３１Ｂのオペレーションを示す。ハイパーバイザ層１３２Ｂは、ＶＭ、ハイパーバイザ、およびオペレーティングシステムがハードウェアアーキテクチャ１３４Ｂ（例えば、市販の（ＣＯＴＳ）ｘ８６アーキテクチャ）上で実行される場合に、ホストオペレーティングシステム１３３Ｂを使用して制御され得る。リアルタイムオーケストレーション１３５Ｂの態様は、コンピューティングシステムのオペレーションのすべてのレベルに統合され得る。したがって、ｘ８６コンピューティングシステムは、本明細書で論じられるクラウドまたはサーバに基づくＳＤＩＳ機能またはオペレーションのいずれかを連携させるように適合され得る。ＣＳノード１３０Ａについて論じられた機能性またはハードウェア構成の他の態様もまた、コンピューティングシステム１３０Ｂに適用可能であり得る。
図３Ｂおよび３Ｃは、それぞれ、図１ＢのＳＤＩＳ動作アーキテクチャ内に配置可能なクラウドコンピューティング１８０およびエッジコンピューティング１９３のサブシステムのより詳細な構成を示す。図３Ａに示されるのと類似の方法では、図３Ｂおよび３Ｃに示される一連の仮想マシン１８１、１９６、ハイパーバイザ層１８２、１９７、ホストオペレーティングシステム１８３、１９８、およびＣＯＴＳのｘ８６ハードウェアアーキテクチャ１８４、１９９が、それぞれのシステム１８０、１９３を実装するように適合され得る。アプリケーションおよびコンテナを使用して、リアルタイムのオーケストレーションの制御下で、クラウドおよびエッジに基づく機能を連携させることができる。ＥＣＮノード１５０について論じられた機能またはハードウェア構成の他の態様もまた、エッジコンピューティングノード１９３に適用可能であり得る。エッジコンピューティングノード１９３は、フィールドデバイスを制御するための制御機能を実装し得る。
本明細書で説明するシステムおよび技術は、「モバイルエッジコンピューティング」（Ｍｏｂｉｌｅ−ｅｄｇｅ Ｃｏｍｐｕｔｉｎｇ）または「マルチアクセスエッジコンピューティング」（Ｍｕｌｔｉ−Ａｃｃｅｓｓ Ｅｄｇｅ Ｃｏｍｐｕｔｉｎｇ：ＭＥＣ）の概念を統合することができ、１つまたは複数のタイプの無線アクセスネットワーク（ＲＡＮ）にアクセスして、コンテンツ、サービス、アプリケーションの速度を向上させることができる。ＭＥＣにより、基地局はインテリジェントなサービスハブとして機能し、高度にパーソナライズされたサービスをエッジネットワークで配信できる。ＭＥＣは、次世代ＳＤＩＳ動作環境で使用されるデバイスを含む、様々なモバイルデバイスに身近で高速の柔軟なソリューションを提供する。例として、ＭＥＣ手法は、欧州電気通信標準化機構（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ：ＥＴＳＩ）がＹｕｎ Ｃｈａｏ ＨｕなどによるＥＴＳＩホワイトペーパーＮｏ．１１（ＩＳＢＮ Ｎｏ．９７９−１０−９２６２０−０８−５）として発行した「モバイルエッジコンピューティング、５Ｇに向けた重要な技術」（Ｍｏｂｉｌｅ−Ｅｄｇｅ Ｃｏｍｐｕｔｉｎｇ， Ａ ｋｅｙ ｔｅｃｈｎｏｌｏｇｙ ｔｏｗａｒｄｓ ５Ｇ）に記載されており、ｈｔｔｐ：／／ｗｗｗ．ｅｔｓｉ．ｏｒｇ／ｎｅｗｓ−ｅｖｅｎｔｓ／ｎｅｗｓ／１００９−２０１５−０９−ｎｅｗｓ−ｎｅｗ−ｗｈｉｔｅ−ｐａｐｅｒ−ｅｔｓｉ−ｓ−ｍｏｂｉｌｅ−ｅｄｇｅ−ｃｏｍｐｕｔｉｎｇ−ｉｎｉｔｉａｔｉｖｅ−ｅｘｐｌａｉｎｅｄで入手可能であり、これは、その全体が本明細書に組み込まれている。５Ｇ／次世代無線ネットワーク、ソフトウェア定義型ネットワーク、およびネットワーク機能仮想化の他の態様が、現在のＳＩＤＳ動作アーキテクチャと共に使用され得ることが理解されよう。
図４は、ＳＤＩＳ動作アーキテクチャ内で使用されるリアルタイムサービスバスの構成例４００（例えば、制御メッセージバス１１２の構成）を示す。この構成は、本明細書で論じられるように、様々な処理制御ノードのサポートを可能にする。例えば、制御メッセージバス１１２は、それぞれの制御処理ノード４１０（ノード４１０Ａ、４１０Ｂ、４１０Ｃ上の様々なハードウェアおよびソフトウェアの実装を含む）およびクラウドに基づくサービスまたは制御サーバ１３０Ａを様々なエッジデバイス４２０（例えば、Ｉ／Ｏコントローラ１５０、１６０、１６５、またはエッジコンピューティングノード１９１、１９３、１９５）に接続するために使用され得る。
例では、制御メッセージバス１１２は、レート単調制御要件を用いて、パケットレベルの確定的制御ネットワークをサポートするように実装され得る。これらの機能は、従来、独自の分散型制御システム（Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ：ＤＣＳ）、監視制御およびデータ取得（Ｓｕｐｅｒｖｉｓｏｒｙ Ｃｏｎｔｒｏｌ Ａｎｄ Ｄａｔａ Ａｃｑｕｉｓｉｔｉｏｎ：ＳＣＡＤＡ）、またはプログラマブルロジックコントローラ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｃｏｎｔｒｏｌｌｅｒ：ＰＬＣ）コンポーネントによって提供されていた。これらのシステムのほとんどは、ノードとデータ要素の数を制限するパラメータを設計するように作られており、施設内の一般的に閉じて分離されたネットワークのデータの量および質を動的に管理する能力はほとんどない。これらのシステムのライフサイクルを通じて、出現した新しいユースケースを実装したいという要望は、高価な制御システムインフラストラクチャの根本的な柔軟性のなさと限られた拡張性とによって厳しく制限されてきた。
以前の手法では、オープンソースとオープン標準に基づくサービスバスミドルウェアオプションとの両方は、ソリューションプロバイダーの重要なミッションエコシステムがこれらの技術を「ベストインブリード」機能として採用し、拡張可能で冗長性が高く、耐故障性のあるリアルタイムシステムを過去のコストの何分の１かで構築するというポイントに成熟した。これにより、コモディティレベルのハードウェアとオープンソース、標準に基づくソフトウェアが収束され、サービス指向のアーキテクチャに基づく設計原則を維持しながら、リアルタイムの計算方法を可能にする不連続処理および連続処理の両方で実現できる新しいユースケースの実現を引き起こした。
例では、ネットワークのプラットフォームノード間およびプラットフォームノード内の両方で時間依存ネットワーキング（Ｔｉｍｅ Ｓｅｎｓｉｔｉｖｅ Ｎｅｔｗｏｒｋｉｎｇ：ＴＳＮ）および時間同期計算（Ｔｉｍｅ Ｃｏｏｒｄｉｎａｔｅｄ Ｃｏｍｐｕｔｅ：ＴＣＣ）可能にすることにより、ハードウェアレベルでリアルタイム計算を可能にすることで、制御メッセージバス技術をさらに拡張できる。独自のソリューションとオープン標準に基づくソリューションとの両方を、ＯＰＣ−ＵＡ（ＯＰＣ統合アーキテクチャ）およびＤＤＳ（データ配信サービス）グループによって提供される業界標準の利用を含むコモディティハードウェア対応の拡張機能と、ロボットおよび機械制御アプリケーションでは不連続モーション制御の厳しいリアルタイム要件が必須となるＳＥＲＣＯＳ標準などの独自の実装とに統合できる。
例において、制御メッセージバスおよび全体的なＳＤＩＳアーキテクチャはまた、インダストリアルインターネットコンソーシアム（ＩＩＣ）機能と統合され得る。これらは、ＴＳＮの産業利用の様々な計画策定およびテスト標準を含み得、パケットレベルのレイテンシとジッターの両方を劇的に低減させることにより、ＤＤＳおよびＯＰＣ−ＵＡの両方に基づくソリューションの両方のパフォーマンスおよびＱｏＳを向上させることができる。さらに、オブジェクト管理グループ（ＯＭＧ）およびＯＰＣ財団標準の態様が、ＯＰＣ−ＵＡの情報モデル化を活用するＯＰＣ−ＵＡおよびＤＤＳ実装モデルの統合の強化、およびアーキテクチャの設計におけるＤＤＳのＱｏＳおよびパフォーマンス能力をサポートするように位置付けられ得る。新しいユースケースは、分析機能と自動機能を含み得る。
例では、ＳＤＩＳアーキテクチャは、ソフトウェア定義型ネットワーキング（ＳＤＮ）機能を使用して統合され得る。ＳＤＮとは、制御プレーンをデータプレーンから分離し、ネットワークおよびネットワーク機能をより柔軟に、よりアジャイルに、より拡張可能にし、かつネットワーキング機器、ベンダー、およびサービスプロバイダーへの依存性を低くするソフトウェアでプログラム可能なネットワークへ向かう動きである。ＳＤＩＳに関連するＳＤＮの２つの重要なユースケースは、侵入検出／防止機能の動的挿入を可能にするサービス機能チェーンと、地域メンテナンスや自然災害などの大規模な停止などのイベントに対応する動的再構成を含む。さらに、ＳＤＩＳアーキテクチャをＳＤＮコントローラと統合して、オープンｖＳｗｉｔｃｈデータベース管理プロトコル（ＯＶＳＤＢ）などのネットワーキングプロトコルを使用して仮想スイッチを制御できる。ＳＤＮ機能の他のユースケースは、動的ネットワーク構成、監視、および仮想化された動的システムでのネットワーク機能の抽象化を含み得る。
図５Ａは、ＳＤＩＳサブシステムの配置例のための第１ネットワーク構成５００を示す。第１ネットワーク構成５００は、冗長な一対のホスト（ノード５１０Ａ、５１０Ｂ）上でコントローラ、ストレージ、および計算機能を組み合わせる、縮小された省スペース型の配置オプションを示す。この構成では、（制御アプリケーションまたは実装の）コントローラ機能はノード５１０Ａ、５１０Ｂに対して有効／スタンバイであるが、（残りのすべてのプロセスの）計算機能は有効／有効であり、つまり、ＶＭを配置していずれかのホストで計算機能を実行できる。
例えば、ＬＶＭ／ｉＳＣＳＩは、計算ノード間で複製されるボリュームバックエンドとして使用され得るが、各ノードには、一時ストレージ用のローカルディスクもある。プロセッサの帯域幅およびメモリも、コントローラ機能用に確保され得る。この２ノードソリューションにより、必要な処理および冗長性が少ない場合に、低コストおよび省スペースがもたらされる。
図５Ｂは、ＳＤＩＳサブシステムの配置のための第２ネットワーク構成を示す。第２ネットワーク構成５５０は、高容量、高拡張性、および高性能を備えた専用ストレージノードを提供し得る。第１ネットワーク構成５００と比較して、第２ネットワーク構成５５０は、コントローラ、ストレージ、および計算機能を別々の物理ホストに配置することを可能にし、ストレージおよび計算容量が相互に独立してスケーリングできるようにする。
例では、第２ネットワーク構成は、高可用性（例えば、Ｃｅｐｈ）クラスタ（例えば、コントローラノード５２０Ａ、５２０Ｂによって連携する）内の最大８つのストレージノード（ノード５３０Ａ〜５３０Ｎ）およびストレージノードあたり８つのディスクの構成から提供され得、高可用性クラスタが計算ノードにイメージ、ボリューム、およびオブジェクトのストレージを提供する。例えば、最大１００個の計算ノード（例えば、ノード５４０）がサポートされ得、各々がＶＭで使用するための独自のローカル一時ストレージを備えている。理解されるように、様々な他のネットワーク構成が、本ＳＤＩＳアーキテクチャを使用して実装され得る。
ＳＤＩＳアーキテクチャとそれに付随するデータフロー、オーケストレーション、および以下に拡張されるその他の機能は、機械学習、認知コンピューティング、および人工知能の態様を利用し得る。例えば、ＳＤＩＳアーキテクチャは、ハードウェアに基づくセキュリティ、相互運用可能なサービス、およびプンソースプロジェクトを基盤し、サイバーセキュリティのためのビッグデータ分析や機械学習の使用を含む参照プラットフォームと統合され得る。ＳＤＩＳアーキテクチャは、不変のハードウェア要素を利用してデバイスの信頼を証明し、機械学習で強化されたフィルターに基づいてネットワークトラフィックの挙動を特徴付けて、悪意のあるトラフィックと良性のトラフィックを区別し得る。
ＳＤＩＳアーキテクチャの様々なコンポーネントを豊富な一連のセキュリティ機能と統合することで、実際の産業環境で相互運用可能で安全な産業システムが可能になり得る。例えば、このようなセキュリティ機能は、ハードウェアに基づく信頼のルート、信頼できる実行環境、保護されたデバイスのアイデンティティ、仮想化機能、および堅牢なリアルタイムセキュリティアーキテクチャが構築され得る暗号化サービスを含み得る。以下のセクションでは、機能的なＳＤＩＳアーキテクチャ配置内のこのようなコンポーネントの構成および機能についてさらに説明する。
［データモデルの概要］
［データモデルの概要］
例では、ＳＤＩＳアーキテクチャはさらに、センサ、アクチュエータ、および他の配置されたコンポーネントからのデータを管理するための様々なデータモデルと統合し得る。数値データの時系列ストリームは、データがどのようにまたはどこで生成されたか、データが収集している測定値は何か、またはその他の特性が不明な場合、有用性が制限される。データモデルは、多くの分野において、ユーザがデータのアイデンティティを分かりにくくしたい極端な場合でも、このような情報のコンテキストを提供するために使用され得る。
データモデルが、データの構造の表現を提供するために定義され得る。また、様々な利害関係者が複数のオブジェクトおよびこのようなオブジェクトが相互にどのように相互作用または関係するかを定義することを可能にするためにも、データモデルが定義され得る。例えば、セマンティックデータモデルが複数の分野で利用され、ＳＤＩＳアーキテクチャ内の様々な情報システム間での処理および保存を支援できる。
例では、セマンティックデータモデルは、次のコンポーネントの任意の組み合わせの態様を定義できる。
・メタデータ：（例えば、データの内容を説明する情報）。例えば、データストリームまたはポイントは、「温度」などの名前を含むメタデータを有することができる。別のメタデータは、データの発生元を示す「２階、ポールＪ２」という場所であり得る。さらに、このようなメタデータは、柔軟で拡張可能であり得る。
・分類：分類では、データはデータポイント間のカテゴリおよび関係を説明できる。分類は、データの分析を実行するための情報、およびこのデータが特定のサイトの他のデータまたはデバイスとどのように関連しているかについての情報を含み得る。タグのライブラリがシステム用に定義され、かつ複数のデバイスの相互動作性およびサポートを保証するように定義され得る。
・オブジェクト構造：どのようなメタデータおよび分類をオブジェクト構造が有してよく、また有するべきかを記述するために使用され得る。
・データフロー：データフローは、データ変換およびフローを記述でき、このようなデータフローは抽象的または物理的であり得る。さらなる例では、データフローは、ＲＥＳＴなどの標準的な定義または手法に依存し得る。
・データストア：特定のデータストア構成のデータストレージおよび利用は、データモデルと、データの作成者および使用者のパフォーマンスとに影響を与え得る。
・メタデータ：（例えば、データの内容を説明する情報）。例えば、データストリームまたはポイントは、「温度」などの名前を含むメタデータを有することができる。別のメタデータは、データの発生元を示す「２階、ポールＪ２」という場所であり得る。さらに、このようなメタデータは、柔軟で拡張可能であり得る。
・分類：分類では、データはデータポイント間のカテゴリおよび関係を説明できる。分類は、データの分析を実行するための情報、およびこのデータが特定のサイトの他のデータまたはデバイスとどのように関連しているかについての情報を含み得る。タグのライブラリがシステム用に定義され、かつ複数のデバイスの相互動作性およびサポートを保証するように定義され得る。
・オブジェクト構造：どのようなメタデータおよび分類をオブジェクト構造が有してよく、また有するべきかを記述するために使用され得る。
・データフロー：データフローは、データ変換およびフローを記述でき、このようなデータフローは抽象的または物理的であり得る。さらなる例では、データフローは、ＲＥＳＴなどの標準的な定義または手法に依存し得る。
・データストア：特定のデータストア構成のデータストレージおよび利用は、データモデルと、データの作成者および使用者のパフォーマンスとに影響を与え得る。
以下の例で拡張されたＳＤＩＳアーキテクチャは、アプリケーションおよびマシン全体でのデータ伝搬の異質性に対処するための共通データモデルを提供し得る。以下でも説明するように、動的データモデルをＳＤＩＳアーキテクチャで利用して、データの構造の抽象的な表現を提供し得、さらに様々な利害関係者が柔軟なデータオブジェクト、それらの表現、およびそれらの相互関係を定義できるようする。これらおよびその他のセマンティックデータモデルは、多くの情報システムの配置における処理と保存に不可欠であり得る。
［動的データモデル］
［動的データモデル］
上記で示したように、データモデルは、ＳＤＩＳ実装などのＩｏＴ配置で使用するための必須コンポーネントであり得る。データモデルは、データの抽象化であり、様々な構造とストリームの関係である。実装に基づいて、データモデルは、オンザフライのような単純なタグ付けで（プロジェクトＨａｙｓｔａｃｋで使用されているものなど、建築機器と動作データの命名規則と分類を開発するオープンソースイニシアチブ）、または構造／クラスとデータのフローの広範な定義で（例えば、このような定義は一般に、設計段階の間およびシステムの開発の前に確立される）実装され得る。データモデルは、開発者、設計者、設計技師、および開発技術者がデータソースを記述および検索するためのメカニズムを提供するため、多くのシステムで重要である。
ほとんどのデータモデルは、定義を作成するために時間と労力（および複数の反復）を伴う。さらに、ほとんどのデータモデルは静的であり、既存のモデルに新しいタグ、コンポーネント、または接続を追加するためにかなりの変更と反復が必要で、多くの場合、下位互換性がない。これにより、開発中にデータモデルが大幅に変更されて、データのアプリケーション（データの視覚化、分析、提供ツールアプリケーションなど）で使用されるタグが記述されなくなる。
既存のソリューションでは、データモデルを定義する際に限られた柔軟性しか提供できず、このようなソリューションは動的ではない。例えば、データ設計者は、複数の特性（これらの特性の一部はオプションである）を用いてデバイスを定義できるが、特定の特性はランタイムに変更され得ない。これにより、データモデルの作成、変更、維持が、特に産業利用環境で非常に複雑になる。
定義により、データモデルの作成は静的になる傾向がある。つまり、データモデルが定義および実装された後、構造（例えば、データ値ではなくデータモデル）に変更を加えると、多くの場合、データモデル用の新しいバージョンのコードの開発作業と配置が必要になる。ただし、これは、アプリケーション、デバイス、またはセンサに動的な一連の機能がある場合のシナリオには対応していない。例としては、バッテリーと計算の可用性に基づいて、様々な出力センサとして表示され得るセンサの集合であるデバイスである。このようなデバイスは、複数の物理センサ（近接、接触、光、ブルートゥース（登録商標）、温度など）を含み得、室内の占有率を報告できる。ただし、何らかの理由でこのデバイスが電力を節約する必要がある場合、またはモジュールが故障している場合、デバイスはそのコンポーネントのサブセットに戻ることができる。このような場合の動的データモデル（および動的メタデータおよび機能）の概念は非常に価値があり、バイナリのオン／オフステータスではなく、タグの確率論的推定などの複雑な表現で実装することもできる。動的データモデルの概念は、オーケストレーションがＩｏＴ環境にいつ配置される（または配置される必要がある）かの予測に役立つ入力を提供もし得る。
次の技術により、動的データモデルの作成および配置が可能になり、ＳＤＩＳアーキテクチャなどの設定におけるこれらおよびその他の技術的な考慮事項に対処できる。動的データモデルでは、データ設計者は、名前、単位、タイプなどの必須である一連のフィールドを識別できる。さらに、データ設計者は、ノードおよびモジュールメタデータ（または任意のタイプおよび数量）を追加するためにの定義をオープンにしたままにしてよく、または、この定義は、追加できるものと誰が追加できるかを制限してよい。
例では、ノードがデータストリームで発生している特定の挙動を検出すると、ノードはセンサにそのメタデータ拡張ルールをクエリできる。例えば、モジュールは分析を使用して予測メンテナンス出力を生成できる。計算の一部として、モデルが教師なし学習を利用する場合、モデルは、感知されたデータの特定のストリームが経時的により重要になり、機能セットに追加されるべきであることを検出できる。機能セットは分析計算にとって重要であり、アプリケーションに依存し、機能セットがリアルタイム要件につながり得る。
例えば、このフラグをメタデータに追加すると、ＴＳＮスイッチは学習アルゴリズムをサポートしてネットワークのトラフィック優先度を高めることができる。動的メタデータが追加される場合、データには有効期限または更新期間が割り当てられる。これは、データがこの特定の機能を引き続きサポートする必要があることを保証する。そうしないと、機能が無効になり、それに応じて更新され得る。あるいは、メタデータが有効でなくなった、または必要なくなった場合に、システムがメタデータの一部を取り消すことを可能にする取り消しメカニズムを実装することもできる。
実装例では、各データストリームはデータストリームマネージャに割り当てられる。データストリームマネージャは、データを生成するデバイス、またはフォグ／クラウドにある仮想実装であり得る。データストリームマネージャは、動的メタデータのポリシーを保持する。システム内の別のモジュールまたはノードが動的データモデルに貢献する必要がある場合、この別のモジュールまたはノードはストリームマネージャに連絡する。次に、ストリームマネージャは、同等のキーを有するトークンをこの別のモジュールまたはノードに提供して、データストリームマネージャがトラフィックを確認および分析する場合に、データストリームマネージャがメタデータを追加および更新できるようにする。
さらなる実装例では、システムは来歴メタデータを追加し得る。来歴は、ノードがストリームの履歴またはメタデータの一部だけを理解するために使用できる所有権と変更の証跡を提供する。
図６は、例による、動的データモデルを確立するためのプロトコルを示す。この例では、センサ６１０はデータフロー６３０においてストリーミングデータを生成する。このデータフローは、複数のノード（例えば、データフロー６３０を監視するサーバ６４０、６５０）によって取得および処理される。データフロー６３０において生成されたセンサデータは、センサ６１０が動的データモデル化をサポートすることを示すためにフラグが付けられる。次に、このセンサデータは、（例えば、サーバ６４０上で動作する）データモデルマネージャによって取得および処理される。
データモデルマネージャは、センサ６１０、および対象のセンサのデータモデルを修正することが可能な他のモジュールならびにデバイスにアクセス可能である限り、ネットワーク内のどこにでも存在し得る。例えば、データが上流に流れる場合、デバイス（例えば、サーバ６５０）は、データストリームがアルゴリズム用の一連の機能において考慮されるべきかどうかを判断するために一連の分析を実行し得る。システムの変更により、デバイスは、センサ６１０によって生成されたデータストリームが、ロボット６２０を制御するプロセスにとって重要であると判断する。次に、デバイスは、その資格情報を含む要求をデータモデルマネージャに送信し、ロボットのアームとの関連性を示すセンサデータストリームを修正するか、またはそのセンサデータストリームにフラグを追加するように要求する。データモデルマネージャは、問題のアルゴリズムにこのような変更を要求する権利があるかどうかを判断する。
事前定義されたポリシーを使用して、データモデルマネージャは、アルゴリズムによって要求された修正を実装するように要求するコマンドをデバイスに送信する。これらの変更はポリシーに基づいて有効になるか、要求の一部になり得る。データモデルに新たに追加されたメタデータには、接続ＱｏＳ（例えば、ＴＳＮ通信の有効化に関与する）などのさらなる要素に影響を与えるなどのさらなる影響があり得る。同様に、何らかの理由でセンサデータがアルゴリズムやアプリケーションで不要になった場合は、データモデルを修正して、問題のタグを省略できる。要求は、タグの完全な削除や、さらなるデータが分析されるまでの一時的な停止さえも含み得る。
図７は、ＳＤＩＳ動作アーキテクチャにおいて動的に更新されたデータモデルを生成および利用するための例示的なプロセスのフローチャート７００を示す。図示されているように、以下のフローチャートは、１つまたは複数のシステムあるいはサブシステム（例えば、図６の構成のサーバ６４０、６５０）によって実行できるいくつかの高レベルのオペレーションを含む。ただし、ＳＤＩＳアーキテクチャでは、接続された様々なセンサやアクチュエータで使用するために、様々なコンピューティングノードやコントローラノード間で、次のオペレーションが適応され得る。
フローチャート７００では、これらのオペレーションは、制御されたシステム内のセンサまたはアクチュエータから提供されるデータフローの監視を含む（オペレーション７１０）。この監視は、データソースからのデータのサンプリング、または任意の数の監視手法を使用して、データストリームで継続的に提供できる。この監視に基づいて、１つまたは複数のパターンをデータフローから検出し得る（オペレーション７２０）。例えば、データ値の組み合わせ、データ値の傾向、データ値の信頼性または確率、あるいは１つまたは複数のデータ値タイプおよびソースによって示される他の値を、１つまたは複数のパターンについて分析し得る。例では、機械学習、人工知能、またはルールをこのパターン検出に使用し得る。
１つまたは複数の検出されたパターンを使用して、データモデルの変更を識別し得る（オペレーション７３０）。例えば、特定のデータ値の組み合わせを使用して、データモデルに追加する集約データ値タイプの追加をトリガーできる。また、例えば、特定のデータ値の傾向または信頼性により、データ値のタイプが削除または変更されることになり得る。次に、識別されたデータモデルの変更は、データモデルに組み込まれ（オペレーション７４０）、様々なシステムコンポーネント間で使用するために配置され得る。その結果、後続のシステムオペレーション（システムコマンドとワークフローを含む）が、データモデルの変更に基づいてシステム配置で実行され得る（オペレーション７５０）。データモデルの変更の結果として、他のタイプのデータ分析およびシステムオペレーションの適応も発生し得る。
上記の動的データモデルの変更に対する拡張として、データストリーム内のタグの存在を使用して、データ値またはデータタイプの信頼レベルを表すこともできる。例えば、特定のデータストリームと分析機能の関連性が、特徴選択コンポーネントを使用して決定されたと仮定する。特徴選択コンポーネントは、このデータストリームの関連性スコアを決定できる。さらなる例として、特徴選択コンポーネントは、データストリーム内の特定の情報フィールドに対して０．８の関連性スコアを生成できる。このような関連性スコアは、データモデルに追加されるメタデータで定義される信頼レベルとして使用され得る。
同様に、同じデータストリームは、占有などの別の情報フィールドに使用されることに対して、関連性のスコアが非常に低い（０．４）場合がある。別のデバイスまたはアルゴリズムが、フィルタを高信頼性に設定して、デバイスにそのメタデータをクエリし得る。その結果、デバイスは０．８の関連性スコアに関連するメタデータを返すが、０．４の関連性スコアのメタデータは省略する。
このような例では、データモデルが動的であるだけでなく、特定のデータフィールドを評価するために使用される関連性スコアも動的であり得、定期的にまたはイベントに基づいて再計算され得る。さらに別の例では、関連性スコアは単一値として定義されず、値に関連する一連の条件と共にベクトルによって表される。ベクトルの例は次のようになり得る。
・タグ：「アルゴリズム」：「占有率」
・信頼性ベクトル［０．７、０．３、０．８］
・コンテキストベクトル［「午前７時〜午後５時」、「午後５時１分〜午後８時」、「午後８時１分〜午前６時５９分」］
・タグ：「アルゴリズム」：「占有率」
・信頼性ベクトル［０．７、０．３、０．８］
・コンテキストベクトル［「午前７時〜午後５時」、「午後５時１分〜午後８時」、「午後８時１分〜午前６時５９分」］
この例では、３つの関連するコンテキストを有する３つの信頼レベルがある。コンテキストは、データの時間のように単純であり得るか、イベントに基づく式を提供するためにさらに複雑であり得る。
前の例を続けて、スマートビルディングの配置で室内の占有率を決定するために光センサが使用されるシナリオを考える。センサ値は、通常の営業時間中の占有状態の正確な指標を提供し得る。ただし、通常の挙動ではなく、多くの照明器具がすばやくオン／オフする営業時間後の清掃員の特別な活動によって、センサの値が狂うことがある。ただし、午後８時を過ぎると、通常は清掃員がいなくなるので、照明の存在を再度、占有率の正確な指標として使用され得る。
動的データモデルにより、生成されたコンテキストとデータ（またはデータの特性）に基づいて、有益なタグの追加および削除が可能になる。これにより、ＳＤＩＳの配置で、これらの拡張を追加または削除するために新しいデータモデルを再作成する必要なしに、トラフィックの優先度、ポリシー、さらには動的タグに基づくルーティングの決定を追加できる。
開発者およびアプリケーションの観点から、動的データモデルをサポートするために、各デバイスは、適切なクエリをサポート、修正し、およびこのようなデバイスのデータモデルに追加する。これらのデバイスは、一連の基準に基づいてデータモデルを返すクエリもサポートする。その結果、データモデルを修正し、追加し、および返すためのデバイスインタフェースが、データモデルのランタイム修正に利用される。
さらなる例では、データモデルを複数のデバイスおよびノード間で同期させることもできる。例えば、アルゴリズムは、会議室に通常配置される特定のセンサが、特定の配置の建物の一部からのデータに基づく占有アルゴリズムに非常に現在関連していると判断できる。その場合は、次いで、センサのデータモデルを修正して、この新しい発見を反映させることができる。さらに、他のセンサは、センサが類似の挙動を示しているかどうかを判断するためにコードを実行するように求められ得る。特徴抽出が類似の挙動を示す場合、データモデルも拡張され得る。その結果、アプリの開発者やシステムインテグレーターでさえ、すべてのセンサで確認されていなくても、修正が発生することを場合によって考慮する可能性がある。このような機能は、精度／確認と、類似のセンサデータが貴重であり、それに応じてルーティングおよび管理する必要があると想定することとの間のトレードオフとして機能し得る。
データモデルに動的に追加されたタグまたはメタデータは、デバイスまたはアルゴリズムがこのようなメタデータのニーズおよび関連性を引き続き確認しない限り、古くなり（例えば、減衰し）、削除されても（関連性スコアを下げることにより）ダウングレード（関連性スコアを下げることにより）されてもよい。このような経時変化により、開発者が識別しなくても、古くなったメタデータの自然な剪定が可能になり得る。基本的な実装では、経時変化は厳密に時間に基づき得る。ただし、他の実装は、使用の欠如に基づく経時変化を含む高度な概念を含み得る。同様に、追加を要求したデバイスまたはアルゴリズムがセンサからのデータを消費していない場合、メタデータは古くなるか保管される可能性がある（例えば、引き続き使用可能であるが、いかなる優先順位も与えられない）。ただし、メタデータを定期的に使用することで（クエリやその他のＱｏＳの決定はシステムによって行われるが）、メタデータの関心レベルを最新に保つことができる。
図８は、ＳＤＩＳ動作アーキテクチャにおいて動的データモデルの態様を維持するための例示的な方法のフローチャート８００を示す。例では、本方法はデータモデル評価のための１つまたは複数の条件を識別するオプションの前提条件（オペレーション８１０）と、データモデルに従ってデータフローで提供されるデータについて、データフローを介して１つまたは複数のセンサからデータを取得する段階（オペレーション８２０）と、データモデル修正のための１つまたは複数の閾値を識別する段階（オペレーション８３０）と、データモデル修正のために、パターンまたはルールおよび識別された閾値を使用して、センサからのデータを評価する段階（オペレーション８４０）とを含み得る。
この方法はさらに、データモデル修正のための機能の追加、変更、または削除を定義する段階（オペレーション８５０）と、データモデル管理者にデータモデル修正の承認を要求する段階（オペレーション８６０）と、データモデル管理者からデータモデル修正の承認を受信し、処理する段階（オペレーション８７０）と、データモデル修正を１つまたは複数のセンサまたはデータフローのデータモデルに組み込む段階（オペレーション８８０）と、データモデル修正に基づくシステムアーキテクチャにおけるデータ処理のための変更を実装する段階（オペレーション８９０）とを含み得る。
これらの動的データモデルのオペレーションのいずれも、上記で説明したさらなる例、シナリオ、または条件に基づいて拡張され得る。さらに、動的データモデルを維持および利用する追加の態様は、現在開示されているＳＤＩＳアーキテクチャの機能オーケストレーションまたは他の管理の特徴に関連して組み合わせることができる。
［機能オーケストレーションの概要］
［機能オーケストレーションの概要］
図９は、ＳＤＩＳ動作アーキテクチャにおける構成可能アプリケーションシステム層（ＣＳＬ）の使用を伴う、動的に確立された一連のオーケストレーションオペレーション９００の例を示す。ＣＳＬを利用して、制御機能とアプリケーションの安全な設計とオーケストレーションを可能にし、産業オペレーションをサポートできる。
例では、ＣＳＬは、各々が制御ループロジックおよびアプリケーションコンポーネントを表す機能ブロック９９０のライブラリ９８０を維持する。各機能ブロックは、他の機能ブロックと相互運用可能であってよい。機能ブロックは複数の実装を有し得、移植性が高いため、様々なプラットフォームアーキテクチャで動作し、使用可能な場合は特別な機能（例えば、ハードウェアアクセラレータ）を利用できる。例では、ＣＳＬはエッジノードのクラスタ（例えば、ＥＣＮ）の制御機能を提供する。さらなる例では、ＣＳＬは、制御サーバ内のＶＭ、またはＳＤＩＳ動作アーキテクチャ内の他の計算点の制御を提供する。
例では、プロセスエンジニア（または他のオペレータ）は、ライブラリ９８０からの既存の機能ブロック９９０を組み合わせて構成することにより、制御フローおよびアプリケーションを定義する。これらの機能ブロック９９０は、アプリケーションロジックまたは制御ループ（例えば、制御ループ９７０、データストレージ、分析モジュール、データ取得または作動モジュールなど）、制御モジュール、または任意の他の計算要素を表すことができる。これらの機能ブロック９９０は再利用可能かつ相互運用可能なため、新しい機能ブロックが必要な場合にのみ、新しいコードを書き込む必要がある。さらなる例において、このような機能ブロックは、グラフィカルなドラッグアンドドロップ環境を使用する制御フローまたはエンドツーエンドアプリケーションを含むエンドツーエンドロジックを実装するために利用され得る。
このアプリケーション設計から開始して、ＣＳＬは、必要な機能ブロックと、それらの機能ブロックを実行するための計算点の要件を指定するオーケストレーションプラン９４０を生成する。以下のセクションで説明するように、オーケストレーション９２０は、オーケストレーションプラン９４０を使用可能な計算および通信リソースにマッピングするプロセスを包含し得る。オーケストレーション９２０は、（例えば、結果として生じるオーケストレーションを様々な制御法則、標準、または要件に適合させるために）制御標準設計９１０に基づいてさらに適合され得る。
例では、ＣＳＬは、ＳＤＩＳネットワーク全体のコンピューティングおよび制御リソースのマップ９３０を維持する。マップ９３０は、データセンター内の仮想マシンから、制御点ならびに接続されたセンサおよびアクチュエータまで、様々な計算点のトポロジを包括する。マップ９３０は、制御点のハードウェア機能および動的特性も含む。マップは定期的に更新されるため、システムはコンポーネントの故障に常に適応できる。オーケストレーション９２０および制御ループ９７０は、監視ロジック９５０および機能配置９６０を使用して通信する。監視ロジック９５０は、マップ９３０への入力として使用されるフィールドデバイスまたは制御ループ９７０からの情報を出力する。機能配置９６０は、制御ループ９７０の入力または状態設定として使用される。
オペレータが新しいアプリケーション定義を配置する場合（例えば、オーケストレーション９２０が制御標準設計９１０から出力を受信する）、オーケストレーション９２０は、機能ブロック９９０をマップ９３０内の使用可能な一連のリソースにどのように最適に合わせるかを決定し、機能ブロック９９０を実装する基礎となるソフトウェアコンポーネントを配置する。エンドツーエンドアプリケーションの配置は、例えば、必要に応じて、サーバ内での仮想マシンの作成、制御ループ（例えば、制御ループ９７０）へのコードの挿入、コンポーネント間の通信パスの作成などを含み得る。また、オーケストレーション９２０は、システム全体の再起動を必要とせずに、計算リソースの故障時に機能ブロックを移行できるように動的であり得る。さらに、コンポーネントの実装に対する更新がプッシュされ、必要に応じてコードを更新させ得る。
ＣＳＬは、参加しているデバイス（エッジノードや制御サーバを含む）との信頼を確立するなどのために、セキュリティ機能およびプライバシー機能も組み込み得る。さらなる例では、ＣＳＬは、新しいデバイスのオンボーディングおよび古くなったデバイスの取り消しに使用されるキー管理と統合され得る。ＣＳＬは、他の機能ブロック９６０との安全な通信を可能にするために、機能ブロック９６０にキーを配信し得る。ＣＳＬはまた、安全なテレメトリおよび制御、配置されたコードの完全性および分離された実行、および機能ブロック９９０間の通信の完全性を提供し得る。
ＳＤＩＳのオーケストレーションアーキテクチャ内で開発されたオーケストレーション機能の追加の例については、次のセクションでさらに説明する。
［分散型でミッションクリティカな作業負荷のオーケストレーション］
［分散型でミッションクリティカな作業負荷のオーケストレーション］
今日のオーケストレーション技術は、主に機能、アプリケーション、仮想マシン、またはコンテナ技術によって実行される。ただし、今日の制御戦略の実装では、分散型アプリケーション間の固有の依存性は、通常、低レイテンシで高周波数のミッションクリティカルなタイムフレームでは管理されない。一般に組み込みシステムの場合、ランタイムにアプリケーションの依存性を管理することの技術的な制限により、動的オーケストレーションはこれまで適用されていなかった。
次の技術は、産業システムのリアルタイムのミッションクリティカルな制御戦略を定義する分散型作業負荷のオーケストレーションに対応している。オーケストレートされた制御戦略は、現在定義されている新しい分散型制御システム（ＤＣＳ）設計で動作し得、不連続、連続、およびバッチ式の製造オペレーションに適用され得る。これらのシステムの場合、リアルタイムのミッションクリティカルな制御アプリケーションは、ＩＥＣ ６１４９９標準に準拠して構築され得、複数のスケジューリングされ、連携された同期または非同期のイベント駆動型構築ブロックアプリケーションの組み合わせとして表され得る。アプリケーション機能が一意であると、これらの定義されたシステムレイテンシ境界内で、これらの構築ブロックを特定の順序と頻度で協調して実行できる。
以下の手法とは対照的に、既存の多くの組み込みアプリケーションは、一般に専用の固定目的ハードウェアで実行される。従来のアプリケーションオーケストレーションでは、完全な制御戦略を構成する他のアプリケーション構築ブロックに対するアプリケーション処理の依存性を考慮しておらず、ミッションクリティカルな制御戦略でエラーなしで実行するには、全体の計算、メモリ、ストレージ、およびスケジューリングが一緒に行われる必要がある。
例では、ＳＤＩＳアーキテクチャの機能は、分散型リソースプール全体で実行される複数の依存型アプリケーション（機能ブロック）の全体的なオーケストレーションおよび管理をサポートし、分散型システム構成に組み込まれた制御戦略レベルでオーケストレーションを可能にするように適合され得る。これにより、期待される削減された総コストでシステム全体の性能を高めながら、動作技術環境に制御戦略のオーケストレーション機能が提供される。例えば、オーケストレーション方法の例には、動的ネットワーク発見、任意のオーケストレーション動作に先立つリソースシミュレーション、およびオーケストレータルールセット決定ツリーの一部として利用されるグローバルリソース最適化および予測と組み合わせたシミュレーションを組み込むことができる。
分散型リソースプールは、次にまたがるアプリケーションを包含し得る。（ａ）単一ネイティブデバイスで実行される単一アプリケーション（追加のネイティブデバイスで第２冗長アプリケーションが使用可能）、（ｂ）複数のネイティブデバイスで実行される複数の連携されたアプリケーション、（ｃ）単一仮想マシンで実行される複数の連携アプリケーション（仮想マシンは単一組み込みデバイスまたはサーバで実行されている）、（ｄ）複数の仮想マシン全体で実行される複数の連携されたアプリケーション（各仮想マシンは専用の組み込みデバイスまたはサーバで実行される）、（ｅ）１つの仮想マシンに含まれる複数のコンテナにまたがる複数の連携されたアプリケーション（仮想マシンは専用の組み込みデバイスまたはサーバで実行される）、または（ｆ）複数のコンテナにまたがる複数の連携されたアプリケーション（複数の組み込みデバイスまたはサーバでコンテナが実行されている）。これらのアプリケーションシナリオの任意の組み合わせも適用され得る。
例では、オーケストレーションは、ノード上の計算リソース（例えば、ＣＰＵまたはＦＰＧＡやＧＰＵなどの専用計算ブロックなど）、特定のデバイス機能（センサ／アクチュエータ、セキュリティデバイス（例えば、ＴＰＭ）、プリインストールされたソフトウェアへのアクセス）、ノード上のストレージリソース（メモリまたはディスク）、ネットワークリソース（レイテンシまたは帯域幅、おそらくＴＳＮによって保証される）などのリソースの測定またはリソースの確保を含み得る。
拡張されたオーケストレータルールセットが、標準的な計算、ストレージ、およびメモリメトリックを超える基準を含めるように定義され、アプリケーションのサイクル時間、アプリケーションのランタイム、アプリケーションの入力／出力信号の依存性、またはアプリケーションプロセスの順序（例えば、どのアプリケーションを他のアプリケーションブロックの前または後に実行するかを指定する強制的な順序）が指定されてよい。このオーケストレーション技術は、ＩＳＡレベルＬ１〜Ｌ３で実行されている複数のアプリケーションにわたって、新しいレベルのシステム冗長性とフェイルオーバーを低コストで可能にしながら、分散型アプリケーションの制御戦略レベルで、低コストのコモディティハードウェアおよびソフトウェアを活用して、制御戦略レベルでより優れたシステム性能を実現する機能を提供し得る。さらに、より広範な制御戦略レベルでのオーケストレーションの感度により、低コストで組み込みシステムの新しいレベルの高可用性が可能になり得る。これにより、オーケストレートされかつ連携された制御アプリケーションの一般的なシステムおよびアプリケーションの稼働時間が増加する一方で、従来の手法で使用可能なものよりも高いＩＳＡレベルでの生産オペレーションの計画外の停止時間が削減され得る。
次のオーケストレーション技術により、システムの冗長性が自動化構成に設計されているシステムで、追加のメンテナンスタスクを（生産の停止時間なしで）実行できるようにもなり得る。これらの技術により、プラットフォームにとらわれない仮想化およびコンテナ化が活用されているベンダーハードウェア間で制御戦略を実行する場合の相互運用性を高めることが可能である。これらの技術は、現在、過去、およびシミュレーションの結果を活用して、リアルタイムオペレーションのための動作技術環境の作業負荷配置を最適化する。さらに、これらの技術は、将来のオーケストレーションイベントの予測を活用して、作業負荷の配置を事前に計画し得る。
例では、分散型リソースプールは、機能ブロックのスケジューリング頻度と、処理割り当ての前後にはアプリケーション制御戦略を実行するためのレイテンシ許容値とを追加して、ネットワーク化されたコンピューティングアセット全体の計算、ストレージ、メモリの組み合わせとして定義される。例えば、制御戦略（またはアプリケーション）は、非常に厳密な時間、ブロック間のスケジューリング、および実行のランタイム要件を備えた、物理的に分散され、連携された一連の構築ブロックによって定義され得る。これらの構築ブロックの時間内のオーケストレーションは、全体的なアプリケーション制御戦略を構成するすべての構築ブロックの実行順序、処理レイテンシ、および完全な実行サイクルに関して連携される。
図１０は、分散型システム構築ブロック１０１０の構成に基づく例示的なカスケード制御アプリケーション１０４０のオーケストレーション構成を示す。具体的には、この図は、ＩＥＣ６１４９９機能ブロック標準に基づく一連の構築ブロック１００５の例を示す。図１０に示すアプリケーションは、最新の分散型制御システムに適用される一般的な階層化戦略を示す。この例では、アプリケーションブロック全体（ブロック１０１０）のサブセットが例示目的で示されている。ただし、示されているすべてのアプリケーションブロックは、特定の実装の依存性として含まれ得る。
図１０に示される制御アプリケーション１０４０の例については、機能ブロックＡ、Ｂ、Ｃ、およびＤ（１０２２、１０２４、１０２６、１０２８）が、制御サブシステムのカスケード制御設計で構成される。各汎用構築ブロック（独立した機能ブロックまたはアプリケーション）は、出力の制御（フローバルブ１０３０）のために、分散型制御戦略の一部として指定されたアルゴリズムを実行する。この例では、制御機能ブロックの出力が入力値として次の機能ブロックに送信される。特定のブロックが、何らかのシステムの異常によりオフラインになった場合、または「切断（ｓｈｅｄ）」された場合、依存構築ブロックへのリンクが手動制御のためにオペレータに戻される。
カスケード戦略を機能させるには、アプリケーションのサイクル時間、アプリケーションのランタイム、アプリケーションの入力／出力信号の依存性、および制御ループの各ブロックのアプリケーションプロセスの順序を維持する必要がある。これらのリンクが生産で失われる場合、はるかに効率の悪いオペレーションが発生し、業界レベルでの大きな固有の損失となる。本技術を用いた拡張されたオーケストレータルールセットの定義は、これらのリソースの問題の各々に対処し得る。
拡張されたオーケストレータルールセット内の機能の階層化により、全体的なオペレーションを保護するために、個々のアプリケーションをオフラインにし、制御レベルを下げ得る疎結合の一連の設計原則を通じて労働者の安全を保護しながら、生産コストに直接影響し、製品の品質およびプロセス効率を改善できるより高度なアルゴリズムを追加できる。このようにアプリケーション制御を階層化しないと、新しいソリューションの実装が困難になり、これらのオペレーションは事故を起こしやすくなる。さらに、これらのアプリケーションアセットを制御戦略レベルでオーケストレートすることで、全体的な稼働時間とシステム性能がさらに向上し、製造およびプロセスのオペレーションに直接貢献する。
従来のＩＴオーケストレーション戦略は一般に、動的方法でシステム周囲の個々のアプリケーションアセット（機能ブロック）を移動する機能を提供する。ただし、この例では、分散型機能ブロックアプリケーションの連携は、特定の制御戦略を定義するすべての機能ブロックにわたってオーケストレートされる。集合的な機能ブロックリンクおよび関連する状態情報は、システムリソース全体でこれらの構築ブロックをオーケストレートするために維持され、アプリケーションをオンラインに保ち、より基本的な安全制御状態への切断を回避する。
図１１は、４つのアプリケーションを含むオーケストレーションシナリオの制御戦略のための例示的なアプリケーション配布マッピングを示し、アプリケーションの冗長性は、仮想マシン配置におけるネイティブ、仮想マシン、コンテナ、および仮想マシン内のコンテナという配置に対する設計１１２０に示されている。示されているように、アプリケーションアセットのオーケストレーションは、様々な計算、ストレージ、メモリ、およびアプリケーションの制約に従って、リソースの動的割り当てを検討するための様々な配置オプションを包含し得る。
なお、図１１に示す場合については、オーケストレーションシナリオ１１１０で定義されたアプリケーション（アプリケーション１から４）は、異なる頻度で実行するように指定されている。この例では、サイクルとランタイムの依存性が、ランタイムでのオーケストレーションの決定における主要な要素である。具体的には、図示の例では、アプリケーション１が３０分のウィンドウ内でオーケストレートされて、制御戦略の実行を確保し得る。アプリケーション２は５秒のウィンドウ内でオーケストレートされて、制御戦略の実行を確保し得る。アプリケーション３および４が１秒のウィンドウ内でオーケストレートされて、制御戦略の実行を確保し得る。オーケストレーションの実行ウィンドウが欠落すると、アプリケーションのリンクが壊れ、オペレーションがループを再び閉じるまで、制御戦略は安全状態に低下する。
図１２は、機能ブロックアプリケーションのタイミング依存性を処理するように適合された例示的なオーケストレーションシナリオ１２１０Ａ、１２１０Ｂを示す。示されているように、アプリケーションを配置してエラーのないオペレーションを維持できる場所を定義する際に、より標準的なリソースメトリックに加えて、アプリケーションサイクル、ランタイム依存性、および現在の状態が重要な役割を果たす。例えば、比較的遅いサイクル時間と周波数で実行する制御戦略は、計算リソースの少ないデバイスで実行でき、制御戦略の他の依存型アプリケーションブロックと同じ場所に配置する必要はない。対照的に、非常に速いサイクル時間と周波数で実行する必要があるアプリケーションは、制御戦略をエラーなしで実行するために、すべて同じデバイスの同じ場所に配置する必要がある場合がある。
図１２の例では、オーケストレーションシナリオ１２１０Ａは、アプリケーション１〜４（アプリケーション配置１２３０Ａ）がシステムの独立したノードにわたって分散されてプロセス１２２０Ａを実施し得るシナリオを示す。対照的に、オーケストレーションシナリオ１２１０Ｂは、サイクルおよびランタイムの制限により、アプリケーション１〜４（アプリケーション配置１２３０Ｂ）がシステムの独立したノードにわたって分散されなくてもよいシナリオを示す。むしろ、アプリケーション１〜４は、プロセス１２２０Ｂを正常に実行するために、任意のオーケストレーションイベントに対して一緒にオーケストレートされる必要がある。
図１３は、オーケストレーションアセット配置の例を示し、オーケストレータ１３１０の制御下でのオーケストレーションアセット（アプリケーション１３２０）の様々な配置を示す。具体的には、この例は、使用可能なシステムリソースに基づいた１つの潜在的な動的アプリケーションの結果を示す。図示されているように、例はＶＭ、コンテナ、ＶＭ＋コンテナ、およびネイティブノードの配置をカバーしている。図１３の例では、ノード１、６、１０、および１４が有効であり、同じオーケストレーション内の異なるアプリケーションが異なるシステム配置タイプでどのように動作し得るかを示す。
図１４は、分散型制御アプリケーション戦略のための例示的なオーケストレーションシーケンスのフローチャート１４００を示す。この例では、各機能ブロックアプリケーションは、システムの異なる計算ノードにある。具体的には、図１４は、制御アプリケーションのオーケストレーションを使用可能なリソース全体にわたって制御実行を中断することなく行うことを効果的に可能にする計算、ストレージ、メモリ、およびネットワークリソースの可用性に加えて、アプリケーションのサイクル時間、アプリケーションのランタイム、アプリケーションの入力／出力信号の依存性、および制御ループの各ブロックのアプリケーションプロセスの順序を考慮したオーケストレーション方法を実装している。
個々の構築（または機能）ブロックのオーケストレーションは、上述した図１４に示すように、完全な制御戦略アプリケーションの定義された境界条件の境界内で行われる。さらに、定義された一連の個々の機能ブロックアプリケーション制約と組み合わせると、現在の状態および履歴情報は、リソース割り当てのための様々なマルチ階層最適化方法を実行する手段を提供し、これは、より広範な制御戦略用のオーケストレーションの可能性のあるフードの予測も含み得る。リアルタイムの最適化と組み合わせた予測および制約の管理により、新しいレベルの組み込みインフラストラクチャの復元力を実現できる。
例では、分散型制御アプリケーションの機能ブロックを監視するオペレーション（オペレーション１４１０）が、現在および過去の状態データの様々な形態を監視する段階を含み得る。この段階には、使用可能な計算オーバーヘッド、使用可能な計算速度、使用可能なストレージ、使用可能なメモリ、アプリケーションのサイクル時間、アプリケーションランタイム、アプリケーションリンクの依存性、アプリケーションプロセスシーケンスの依存性、またはアプリケーション固有のオーケストレーションエラーの監視が含まれてよい。
さらに別の例では、更新予測のオペレーション（オペレーション１４２０）には、オーケストレーション最適化＝ｆ（現在の状態データ、過去の状態データ、制約）が制御戦略ごとに、オーケストレーションの最適化＝アプリケーションのｆ（現在の状態データ、過去の状態データ、制約）が構築ブロックごとに、または、オーケストレーション予測＝ｆ（現在の状態データ、過去の状態データ、制約）がアプリケーション構築ブロックごとに含まれてよい。
さらなる例では、アプリケーション構築ブロックのシステム異常を検出するオペレーション（オペレーション１４３０）を評価し得る。これらは、アプリケーションごとに定義された制約、例えば、計算オーバーヘッドの許容限度、計算速度の最小要件、ストレージの最小要件、メモリの最小要件、アプリケーションのサイクル時間制限、アプリケーションのランタイム制限、入出力依存性に対するアプリケーションリンクの依存性、入出力変数のアプリケーションプロセスシーケンスの依存性、オーケストレーションイベントのアプリケーションシステムエラートリガーなどの影響を受け得る。
さらに別の例では、オペレーションが、任意の機能ブロックのオーケストレーションが必要かどうかを評価し得る（オペレーション１４４０）。例えば、アプリケーションの制約１．．ｎが違反している場合、オーケストレーションイベントが必要である。さらに別の例では、オペレーションが、制御戦略オーケストレーションが実行可能かどうかも評価し得る（オペレーション１４５０）。この段階は、定義された制約内でアプリケーションを別のノードに移動する必要があるかどうか、アプリケーションの依存性のために複数のアプリケーションを移動する必要があるかどうかを評価し、また必要に応じて、アプリケーションのグループを分散してよいか、そしてどのように分散するかを評価し得る。さらに別の例では、オーケストレーションが、実行不可能である場合に、低下または切断の制御戦略が実装され得（オペレーション１４６０）、有効機能ブロックプロファイルがそれに応じて更新され得る（オペレーション１４８０）。
さらに別の例では、機能ブロックのオーケストレーションが必要であり、制御戦略のオーケストレーションが実行可能であるという確認に応答して、制御戦略の構築ブロックアプリケーションをオーケストレートするオペレーションが実行される（オペレーション１４７０）。オーケストレーションが成功した場合、これにより予測がリセットされる（オペレーション１４９０）。オーケストレーションが失敗した場合、これにより、低下または切断の制御戦略が使用され（オペレーション１４６０）、有効機能ブロックプロファイルが更新される（オペレーション１４８０）。
図１５は、分散型リソースプールを使用して、分散型でミッションクリティカな作業負荷およびアプリケーションをオーケストレートするための例示的な方法のフローチャートを示す。前の例に基づいて、この方法は、（例えば、図１０〜１３を参照して図示および説明されているように）拡張された一連のアプリケーション固有の依存性に基づいて、分散型および依存型アプリケーションのグループを動的にオーケストレートする機能を可能にする。この方法では、オーケストレーション戦略を実行する前に、ネットワーク帯域幅を動的に分析およびシミュレーションする機能も可能にできる。この方法は、オーケストレーションイベントが発生する前にそれを予測し、制御戦略の作業負荷オーケストレーションの潜在的な最適化されたリソース配置を事前に計画する機能も提供し得る。
フローチャート１５００では、例示的なこれらのオペレーションは、アプリケーション固有の依存性を識別する段階（オペレーション１５１０）と、識別された依存性に基づいて、分散型アプリケーションと依存型アプリケーションのオーケストレーショングループを動的に作成する段階（オペレーション１５２０）と、これらのオーケストレーショングループを使用して、オーケストレーションイベントを予測する段階（オペレーション１５４０）とを含む。例では、オーケストレーションイベントを予測する段階は、例示的なシナリオでネットワーク帯域幅（または他のリソース）を動的に分析およびシミュレーションする段階（オペレーション１５３０）と、この例示的なシナリオにおけるオーケストレーションイベントの発生を分析する段階とを含む。
予測されたオーケストレーションイベントに基づいて、拡張されたオーケストレータロジックルールセットを定義および変更するオペレーションを実行できる。これらのオペレーションは、予測されたオーケストレーションイベントを検出する段階（オペレーション１５５０）、および予測されたオーケストレーションイベントに基づいてリソース配置を最適化する段階（オペレーション１５６０）も含み得る。例えば、図１４を参照して論じられた技術は、変更されたオーケストレーション戦略の態様を組み込むことができる。
［レガシー（ブラウンフィールド）環境のオーケストレーション］
［レガシー（ブラウンフィールド）環境のオーケストレーション］
オーケストレーションとは、アプリケーション（多くの処理、ネットワーキング、および／またはストレージコンポーネントで構成され得る）に対するユーザの要件を現実世界の機能に一致させ、（現実世界を構成し、アプリケーションコンポーネントを分散および構成するなどによって）アプリケーションを配置する行為である。多くの場合、オーケストレーションは企業環境に適用され、拡張性の高いサービスを同種の仮想化環境に配置する。これらのアプリケーションは、この環境で動作するように設計されている。
オーケストレーションがＩｏＴ環境に適用されると、特に既存の（「レガシー」）デバイスを使用する環境（例えば、「ブラウンフィールド」配置）では、問題がいくつかの点で変化する。多くの場合、デバイスが多数存在する。一連のターゲットデバイスは異種性が非常に高い。一部のアプリケーションコンポーネントは、オーケストレートされるように設計されていなくてもよい。一部のハードウェアデバイスは、オーケストレーションソリューションの使用に設計されていなくてもよい。また、一部のデバイスは、独自の閉／固定機能デバイスであってよい。
従来の手法では、ソフトウェアモジュールはオーケストレートされる特定のＡＰＩに準拠する必要があるため、適切に配置および構成できる。通常、オーケストレートされているソフトウェアを受信するために、ハードウェアノードはオーケストレーションソフトウェアを実行し、実行されているソフトウェアに特定のＡＰＩを提供する。したがって、発生する可能性のあるいくつかの問題は次に挙げることを含む。多くのデバイスおよびアプリケーションをどのようにスケーリングするか、修正なしでオーケストレートされるように設計されていないソフトウェアモジュールのオーケストレーションをどのように可能にするか、そうでなければオーケストレーションスタックをサポートできないレガシーハードウェアノードまたはハードウェアノードへのソフトウェアモジュールのオーケストレーションどのように可能にするか、リソース使用率を管理するために、一連の異種物理ノードをどのように自己監視するかという問題である。
例では、以下の技術により、オーケストレーション認識シムの内側にコードをラップすることで、オーケストレーション非認識コードをオーケストレートすることが可能になる。さらなる例では、以下の技術により、オーケストレーション非認識デバイスがオーケストレーションに参加できるようになる。対照的に、従来の手法では、オーケストレーションの問題（特に、異種環境でのエンドツーエンドのオーケストレーション）を考慮していないため、大幅に異なる問題および要件が発生する。また、さらなる例では、オーケストレーションの自己監視を利用して、故障から学習し、フィードバックをより優れたオーケストレーション手法に組み込む、自立的で自己管理されたオーケストレーションを可能にし得る。
オーケストレーション技術を使用すると、リソースの機能とアプリケーションの要件および制約を考慮しながら、分散型ＩｏＴアプリケーションの個々のソフトウェアコンポーネントを、一連の使用可能なハードウェアリソース全体に動的に配置できる。現在のオーケストレーション技術は、（１）ソフトウェアコンポーネントがオーケストレーションＡＰＩを実装することによってオーケストレートされるように設計され、（２）デバイスがオーケストレーションミドルウェアを提供することによってオーケストレーション可能なソフトウェアを受信するように設計されていると想定する傾向がある。本明細書での技術は、オーケストレーション可能なコンポーネントの内部にこのようなレガシーコンポーネントをラップすることにより、レガシーソフトウェアコンポーネントのオーケストレーションを可能にし、標準的なメカニズムまたはカスタムメカニズムでレガシーソフトウェアと相互作用するためのプラグインアーキテクチャを提供する。例えば、標準的なプラグインは、オーケストレーションＡＰＩから通信ポート番号を受信し、構成ファイルまたは環境変数を介して、ウェブサーバなどの標準的なソフトウェアにポート番号を設定することができる。また、例えば、独自のソフトウェアをサポートするようにカスタムプラグインが、書き込まれ得る。
図１６Ａは、オーケストレーションエンジン１６１０Ａと関連するモジュールとの間のオーケストレーションの例示的なシナリオを示す。示されるように、オーケストレーションエンジン１６１０Ａは、２つのオーケストレーション可能なモジュール１６２０Ａ、１６３０Ａを配置する。２つのモジュールは各々オーケストレーションＡＰＩ（それぞれ１６４０Ａ、１６４０Ｂ）を使用して、オーケストレーションエンジン１６１０Ａから構成パラメータを受信する。例えば、モジュール１（１６２０Ａ）がｈｔｔｐクライアントであり、モジュール２（１６３０）がｈｔｔｐサーバである場合、モジュール１（１６２０Ａ）は、このモジュールがモジュール２（１６３０）と通信するために必要なエンドポイント情報、例えばＩＰアドレスおよびポート番号を受信し得る。場合によっては、モジュール２（１６３０）がバインドするべきポート番号は、オーケストレーションエンジン１６１０Ａによってモジュール２（１６３０）に提供されるが、他の場合では、モジュール２（１６３０）は、バインド後にオーケストレーションエンジンに通信情報を提供し得る。どちらの場合でも、２つのモジュールが、通信パラメータを確立して接続されるようになるために、ＡＰＩ（例えば、ＡＰＩ １６４０Ａ、１６４０Ｂ）が使用される。
図１６Ｂは、オーケストレーションエンジンと関連モジュール（レガシーモジュールを含む）との間のオーケストレーションの例示的なを示す。オーケストレーションエンジン１６１０Ｂは２つの異なるモジュール（１６２０Ｂおよび１６６０）を配置する。１つはオーケストレーションを認識したモジュールであり、もう１つはオーケストレーションを認識しないレガシーモジュールである。この場合、オーケストレーションエンジン１６１０Ｂは、レガシーモジュール１６６０とともにシム層１６５０も配置する。このシム層１６５０は、レガシーモジュール１６６０に関連するあらゆるカスタム構成メカニズムを理解している。例えば、レガシーモジュール１６６０がＡｐａｃｈｅウェブサーバであった場合、シム層１６５０は、オーケストレーションＡＰＩ（１６４０Ｄ）を介してポート番号をネゴシエートし、次いで、Ａｐａｃｈｅサーバの起動前に構成ファイル、コマンドラインパラメータ、または環境変数（または類似のメカニズム）を使用してウェブサーバのポート番号を設定するように構成され得る。オーケストレーション可能なモジュール１６４０Ｃのクライアントは、前の例と同じように動作し、オーケストレーション可能なＡＰＩ １６４０を使用してクライアント通信パラメータをネゴシエートし、したがって、Ａｐａｃｈｅ ウェブサーバに接続できる。
例では、レガシーハードウェアデバイスによって実行される作業負荷は、各レガシーデバイスをオーケストレーション可能なデバイスとペアリングすることにより、類似の方法で処理され得る。例として、図１７Ａは、オーケストレーション可能なデバイスを用いたオーケストレーションのシナリオを示す。オーケストレーション可能なデバイス１７１０Ａのエージェントは、デバイスの使用可能なリソースに関する情報を収集し、その情報をテレメトリとしてオーケストレーションエンジン１７２０Ａに報告する。典型的なオーケストレーション可能なデバイスは、その機能をオーケストレータに対して表すことができ、オーケストレータから作業負荷実行要求を受信して、作業負荷１７３０Ａを実行できる。レガシーデバイスはこれらの機能をサポートしていないため、オーケストレーション可能なデバイスとペアリングされている。
さらなる例として、図１７Ｂは、レガシーデバイス１７８０を用いたオーケストレーションのシナリオを示す。各オーケストレーション可能なデバイス（例えば、デバイス１７５０Ｂ）は、オーケストレーションシステムに対してレガシーシステムの機能を表す。オーケストレーションシステムがレガシーシステムに対する作業負荷を要求すると、ペアリングされたデバイスがは、レガシーデバイスで機能を実行させる役割を果たす。これは、遠隔手順コールまたはカスタムＡＰＩの形をとることができる。その結果、オーケストレーションエンジン１７２０Ｂは、適切な作業負荷をデバイスに一致させて配置できる。レガシーデバイスの場合、レガシーデバイス１７８０とペアリングされているオーケストレーション可能なデバイス１７５０Ｂ上のエージェントが、レガシーデバイス１７８０の存在を発見し、このレガシーデバイスの能力を（例えば、ＲＰＣメカニズムを介して）測定できる。この情報は、次いで、エージェントによってテレメトリ１７４０Ｂとしてオーケストレーションエンジン１７１０Ｂに渡される。オーケストレーションエンジン１７２０Ｂがレガシーデバイス１７８０用の作業負荷１７３０Ｂを渡すと、エージェント１７６０Ｂはそれをレガシーデバイス１７８０に（例えば、ＲＰＣメカニズムを介して）配置する。したがって、ラッパーメカニズムにより、レガシーハードウェアおよびソフトウェアの両方を最新のＩｏＴオーケストレーションソリューションに参加することが可能になる。
オーケストレーション技術は通常、フラットな一連のリソースのスケジューリングと管理を提供する。オーケストレートされているリソースは、計算（物理または仮想デバイス）、ネットワーキング（物理または仮想インタフェース、リンク、またはスイッチング機器）、またはストレージ機能（データベースまたはストレージデバイス）を含み得る。オーケストレーションは、タスク（実行の単位）オーケストレーション、コンテナオーケストレーション、仮想マシンオーケストレーション、ネットワークオーケストレーション、またはストレージオーケストレーションの形式をとり得る。または、オーケストレーションのすべてを一度に実行し、エンドツーエンドのアプリケーションオーケストレーションの形式をとり得る。
図１８は、単一レベルのオーケストレーション環境における作業負荷オーケストレーションの連携されたシナリオを示す。この単一レベルのオーケストレーション環境は、すべてのプラットフォームがオーケストレーションに等しく参加するシナリオを示す。各ノード（例えば、ノード１８３０Ａ、１８３０Ｂ、１８３０Ｃ）は、オーケストレーションエンジン１８２０（通常、オーケストレータ１８１０などに一元化される）に使用可能なリソースを記述し、テレメトリを送信することによりスケジューリング機能を実行し、オーケストレーションエンジン１８２０は、ノードのサブセットを割り当てて、全体的なアプリケーション作業負荷の一部を実行する。したがって、図１８に示すように、様々な作業負荷（１８２１Ａ、１８２１Ｂ、１８２２、１８２３Ａ、１８２３Ｂ）が様々なノード１８３０Ａ、１８３０Ｂ、１８３０Ｃに分散され、それぞれのエージェント１８４０Ａ、１８４０Ｂ、１８４０Ｃを使用して実行される。この手法は、フラットなオーケストレーション構造を提供し、各ノードがオーケストレーションプロセスに完全に参加できるように、個々のノード１８３０Ａ、１８３０Ｂ、１８３０Ｃの最小レベルの機能を意味する。
ただし、オーケストレーションは、様々な機能と機能オペレーションとに分離することにより階層化され得る。図１９は、オーケストレーションの例示的な機能階層を示し、アプリケーションオーケストレーション１９１０がオーケストレーションの制御するトップレベルドメインをどのように提供するかを示す。エンドツーエンドのアプリケーションオーケストレーションがトップレベルで実現される場合、ネットワークオーケストレーション１９２０、仮想マシンオーケストレーション１９３０、タスクオーケストレーション１９４０、およびストレージオーケストレーション１９５０の詳細は、サブオーケストレーションモジュールに委任され得る。サブオーケストレータは、各副次的問題をどのように最適化し、各サブドメインのリソースをどのように構成するかを決定するために使用され得る。
図２０は、一般的な階層オーケストレーションソリューションの配置例を示す。図２０の配置は、サブオーケストレータ２０４０Ａ、２０４０Ｂ、２０４０Ｃの一般的な階層を示しており、オーケストレーション可能なデバイスのプールは、全体的なアプリケーションの一部を実装するように要求され得る。
例において、各サブオーケストレータ（例えば、２０４０Ａ〜Ｃ）は、オーケストレーション可能なデバイスの特定のプール内のオーケストレーション可能なデバイス（例えば、２０５０Ａ〜２０５０Ｇ）からテレメトリを受信する。テレメトリは、そのプールで使用可能なリソースを示す。サブオーケストレータはそのテレメトリを集約し、トップレベルのオーケストレータ２０１０に転送する。トップレベルのオーケストレータはサブオーケストレータ（２０４０Ａ〜Ｃ）からテレメトリを受信し、そのプールで使用可能なリソースの合計をトップレベルのオーケストレータ２０１０に通知する。次に、トップレベルのオーケストレータ２０１０は、テレメトリに基づいて、全体的な作業負荷のサブセットをそのオーケストレーションエンジン２０２０に割り当てる。次に、サブオーケストレータは、作業負荷のサブセットをプール内の各オーケストレーション可能なデバイスにスケジュールする。この例では２つのレベルのオーケストレーションが使用されているが、追加のレベルを実装できることに留意されたい。
一部のシナリオでは、リソースが時間と空間の両方にわたって（プール間で）で共有され得ると想定して、オーケストレータ２０１０が１つのプールのリソースをオーバーサブスクライブする可能性がある。さらに、サブオーケストレータは、十分に活用されていないプールからデバイスを借りて、負荷の余剰を一時的に処理できる場合がある。例えば、図２０の例では、クラスタ１（２０３０Ａ）が過負荷になると、１つまたは複数のスレーブをクラスタ２（２０３０Ｂ）またはクラスタ３（２０３０Ｃ）から借りることができる。
図２０で示される手法は、すべてのデバイスがオーケストレーション可能であると想定しているが、実際には、オーケストレーション可能なデバイスの多くは、最小限のメモリとストレージを備えた非常に低コストのマイクロコントローラであり得る。おそらく数百または数千のこれらの低コスト感知ソリューションの各グループは、次いで、より高性能なデバイスによって制御され得る。このシナリオに対処するために、図２１は、スレーブノードを使用して提供される階層オーケストレーションの例を示す。
図２１のシナリオは、上記の階層オーケストレーションシナリオで説明したのと類似の手法を提供し、マスターのオーケストレーションデバイス２１１０は、他の多くのスレーブノードの機能を表すことができる。このような機能は、例えば、特定のセンサデバイスから感知する機能や、特定のＦＰＧＡ部で計算を実行する機能を含み得る。エージェントはそれらの機能をオーケストレータ２１１０まで報告するわけではなく、オーケストレータ２１１０は、作業負荷をその個々のマスターのオーケストレーション可能なデバイスに割り当てる。ただし、マスターノードは必ずしもその作業負荷を実行するわけではなく、代わりに、作業負荷に必要な個々の機能を有するスレーブノード（例えば、ノード２１５０Ａ〜２１５０Ｈ）に作業負荷を委託できる。このプロセスはオーケストレータ２１１０に対して透過的に行われ、オーケストレータ２１１０は作業が実行されることのみを考慮する。
このマスター／スレーブ関係を可能にするために、スレーブノードにいくつかの単純なプリミティブが実装され、これは次のものを含む。（ａ）検出：スレーブノードの存在をマスターノードが検出しなければならず、およびスレーブノードの故障（したがって配置された作業負荷）も検出しなければならない。（ｂ）発見：スレーブノードで使用可能なリソースをマスターノードが発見可能できなければならず、このような情報は、配置され得る作業負荷のタイプと数を決定するのに役立つ。（ｃ）配置：マスターノードが作業負荷をスレーブノードに配置できるようにする配置（例えば、ＲＰＣ、ファームウェア配置など）。
図２２は、階層オーケストレーションシナリオで使用するためのスレーブノードの例示的なワークフローを示す。例では、ノードは、そのクラスタを先導するオーケストレーション可能なマスターデバイスからの発見要求の受信（オペレーション２２１０）を待つ。この間、このノードは低電力状態で待機している可能性がある。要求は、スレーブノードによって暗号化されるナンスなどの、何らかの種類暗号課題を含み得る。スレーブノードがこの要求を受信する場合、スレーブノードは、ノードがクラスタに属していることを証明するために、いくつかの資格情報を送り返すことができる（オペレーション２２２０）。例えば、ノードはナンスを秘密キーで暗号化し、その結果を送り返すことができる。スレーブノードは、一連の機能の形式でテレメトリをクラスタリーダーに送信することもできる（オペレーション２２３０）。次に、スレーブノードは、おそらく実行される作業負荷の形で、その命令を待つ（オペレーション２２４０）。スレーブノードが作業負荷を受信する場合（オペレーション２２５０）、スレーブは自身を再プログラムする必要があり（オペレーション２２６０）、おそらくそのプログラマブルメモリを再フラッシュする必要がある。再プログラミング後、スレーブノードは作業負荷の実行を続行できる（オペレーション２２７０）。
階層型ソリューションであるスケジューリングを設定すると、複雑になり得る。例えば、マスターノードのエージェントは、エージェントが表すリソース間の関係を適切に記述するように注意する必要があり、これにより、オーケストレータは、リソースが実際に多数のスレーブノードに分散している場合に、それらのリソースが実際に同じノードに配置されていると誤って信じないようにする。
上記の階層オーケストレーションメカニズムは、本質的に異種性が高い動的ＳＤＩＳソリューションを作成によって、そうでなければオーケストレーションに完全に参加しない限られた（そして安価な）リソースを備えたコンポーネントを使用できるようにすることなどを可能にする。さらに、この配置では、少数のＩＡに基づくノード（高価なリソース）をマスターノードとして使用できるため、各クラスタにオーケストレーションメカニズムが提供される。
非常に大規模なＩｏＴフレームワークでは、特定のハードウェアコンポーネントにどのソフトウェアを配置するかに関してオーケストレーションが選択したソリューションは最初は正しい場合があるが、これは経時的に変化し得る。さらに、システムの使用可能なリソースが不足しないように、システム全体の容量を監視する必要がある。したがって、ＣＰＵ過負荷などのソフトウェアおよびハードウェアの問題の全体的なソリューションを監視し、それを解決するための適切な段階を実行する必要がある。以下の技術は、故障から学習し、フィードバックをより優れたオーケストレーションに組み込む、自動的で自己組織的なオーケストレーションを可能にする。
さらなる例では、制御ループのようなチェックおよびフィードバックメカニズムが、上で論じられたオーケストレーション手法に追加され得る。ソフトウェア、ネットワーキング、ストレージおよび処理を含む個々のコンポーネントには、監視メカニズムが組み込まれている場合や、このような管理を可能にするために頻繁なポーリングが必要な場合がある。これは、使用可能なすべてのリソースを追跡するオーケストレーション層を拡張して、ＣＰＵ、メモリ、アプリの応答の遅延、アプリの挙動、ネットワークの遅延、ネットワークの帯域幅、特定のハードウェアなど、監視に必要なオペレーションのタグを含めることで提供できる。
図２３は、オーケストレーション自己監視機能の連携および実装に適合された監視およびフィードバックコントローラ２３１０の構成例を示す。例では、監視およびフィードバックコントローラ２３１０は、様々なクライアントノード２３５０、２３６０からソフトウェアデータ２３２０、ハードウェアデータ２３３０、およびネットワークデータ２３４０を収集する。これらのクライアントノード２３５０、２３６０は、次いで、オーケストレーションサーバ２３７０の指示の下で、オーケストレートされたオペレーションと作業負荷を動作する。
例では、クライアントノード２３５０、２３６０は、ハードウェアおよびソフトウェアの過負荷について監視される。例えば、デバイスのＣＰＵまたはメモリが容量の５０％に達した場合、デバイスを厳密に監視できる。容量が８０％に達した場合、デバイスが交換され得るか、作業負荷が実行中の作業負荷によりよく一致するものに作業負荷が移行され得る。ハードウェアの依存性がある場合は、追加のノードを追加してソフトウェアの負荷を吸収できる。類似の例では、ネットワークトラフィックも監視できる。大量の未知のトラフィックが見られる場合、または予想よりも少ないトラフィックが見られる場合、システムはクライアントノードの性能をチェックできる。このようなチェックは、ハッキングやネットワーク接続の喪失も示唆し得る。
監視およびフィードバックコントローラ２３１０は、挙動を動的に制御する管理サーバへのループバックを可能にする。フィードバックループは、クライアントノードだけでなく、サーバも対象としている。例えば、監視メカニズムは、おそらくサーバ間のネットワークトラフィックを監視することにより、サーバノードの性能を監視できる。例えば、サーバクラスタの正常性を監視し、選出されたリーダーが常に使用可能であることを保証するゴシッププロトコルが帯域幅を大量に消費している場合、プロトコルパラメータを動的に修正して、サーバの現在の数、リンクの状態、およびトラフィックレベルにより適切に合わせることができる。
監視およびフィードバックコントローラ２３１０はまた、故障から学ぶためのロジックを組み込み得る。ノードが一貫して故障した場合は、基本的なハードウェアに問題があり得、ノードのメンテナンスがスケジューリングされ得る。特定の物理領域で故障しているノードが多数ある場合は、パターンが検出され得、ノードが手動で検査されるようにスケジューリングされ得る。さらなる例では、ノードは潜在的な問題について自分自身を監視し得る。例えば、監視ソリューションが個々のノードをポーリングしてその正常性を判断する必要がるのではなく、各ノードが自分自身を監視し得る。例えば、ノードがメモリ上で不足している場合、その状態を中央モニタに報告し得る。
自己監視および管理の他の態様も、オーケストレーションに関連して組み込まれ得る。システムは、個々のノードの修復スケジュールを指定できる。各ノードは、特定の動作時間の後にサービスに対してスケジューされ得る。その時点で、ノードはオーケストレータによるスケジュールに使用可能な一連のノードから取り出される。
さらなる例では、自己監視機能も容量計画を提供し得る。例えば、ネットワーキングまたは処理の使用量が容量に近づいている場合、容量を増やすようにオペレータに通知し得る。このシステムは、必要なリソースの数と種類を指定することにより、オペレータが計画を立てるのに役立ち得る。例えば、システムは、タスクを配置できる追加のノードが必要であり、それらのノードには特定の最小メモリとストレージ容量が必要であることを指定できる。このような自己監視機能により、オーケストレーションソリューションは拡張性が高く、インフラストラクチャに簡単に適合できる。
図２４は、レガシー設定においてデバイスをオーケストレートするための例示的な方法のフローチャート２４００を示す。示されているように、フローチャート２４００は、レガシーコンポーネントとの通信の確立、組織化されたオーケストレーションの確立、およびオーケストレーションの動作、監視、調節の機能を備えた、ブラウンフィールド環境でオーケストレーションを構成および動作する一連のエンドツーエンド動作を含む。フローチャート２４００は、例示の目的で高レベルで提供され、上記の追加の構成および使用オペレーションは、動作フロー内に統合され得ることが理解されよう。
示されるように、フローチャート２４００は、オーケストレーションシムを確立してレガシーソフトウェアモジュールを構成するオペレーション（オペレーション２４１０）、オーケストレーションシムＡＰＩを介して構成をレガシーソフトウェアモジュールに通信し（オペレーション２４２０）、オーケストレーション可能なデバイスエージェントを介してレガシーハードウェアデバイスからテレメトリを収集する（オペレーション２４３０）オペレーションを含む。さらなる構成オペレーション（図１６Ａ〜１７Ｂに示され論じられるオペレーションを含む）は、オーケストレーション可能なハードウェアデバイスおよびオーケストレーション可能なソフトウェアモジュールの構成を含み得る。
また示されるように、フローチャート２４００は、構成されたレガシーおよびオーケストレーション可能なコンポーネントなどのコンポーネントの階層を組織化するオペレーション（オペレーション２４４０）を含む。この組織は、コンポーネントを様々な階層に組織化する段階（オペレーション２４５０）、および様々なスレーブノードコンポーネントの検出、発見、および配置を実行する段階（オペレーション２４６０）を含み得る。さらなる検出および階層組織（図１８〜２２に示され、論じられるオペレーションを含む）も起こり得る。
また示されているように、フローチャート２４００は、テレメトリおよび階層内のコンポーネントからその他の構成データに基づいて、作業負荷をコンポーネントの階層内の様々なコンポーネントに分散するオペレーション（オペレーション２４７０）（図１８〜２２に示され、説明されているオペレーションを含む）で終了する。フローチャート２４００はさらに、組織化された（階層）オーケストレーション（オペレーション２４８０）のコンポーネント間でソフトウェアデータ、ハードウェアデータ、およびネットワークデータを収集および監視することなど（図２３に示され論じられたオペレーションを含む）によって、自己監視および構成変更を許可するように動作し、それに応じて、オーケストレータ、管理者、または他のエンティティは、組織化されたオーケストレーションの様々なコンポーネントにフィードバックおよび制御を提供し得る（オペレーション２４９０）。
［自己記述的オーケストレーションコンポーネント］
［自己記述的オーケストレーションコンポーネント］
産業ソリューションの開発では、エンジニアは、ＩｏＴシステムに配置できるモジュールのグラフとしてソリューションを設計できる。図２５は、例示的な産業制御アプリケーションのシナリオを示しており、ヒーター２５３６で周囲のオイルジャケットを加熱することにより水のタンク２５３０の温度を維持する問題を具体的に示す。水の温度および油の温度は、プロセスを制御するために、それぞれのセンサ２５３２、２５３４によって監視される。一連の計算ノード２５２０が使用可能であり得、その上にソフトウェアモジュールが配置され得、それらのいくつかは、システムにおける物理的センサおよびアクチュエータに接続され得る。
この例では、制御エンジニアは、制御システムアプリケーション２５１０を設計して、使用可能な計算ノードに配置できるソフトウェアモジュールのグラフで構成されるカスケード制御ループとして温度を制御するなど、機能オペレーションを実行し得る。センサモジュールは、水中のセンサから値を読み取るマスターセンサ２５３２からデータを読み取ることができる。この値は、ＰＩＤ（比例積分微分）コントローラモジュール（例えば、１つまたは複数の比例、積分、または微分制御要素を有するコントローラ）の入力に供給され、特定の設定点に適合しようとする。このＰＩＤコントローラの出力はスケーリングモジュールに供給され、その出力は別のＰＩＤコントローラの設定値を確立する。この第２ＰＩＤコントローラは、石油内のセンサ（例えば、スレーブセンサ２５３４）から読み取るモジュールから入力を受信する。第２ＰＩＤコントローラの出力は、ヒーター要素２５３６を制御するアクチュエータモジュールに送信される。例では、いずれかのＰＩＤコントローラは、任意の数の機能オペレーションの一部として、比例、積分、または微分制御（単独または任意の組み合わせで）を組み込んだタイプのコントローラであり得る。
このような構成を適切に配置するために、制御エンジニアは、制御アプリケーション、および制御アプリケーション内の機能およびオペレーションについて説明する。次の手法では、制御システムアプリケーションを記述するための言語の構成を定義する技術について説明する。次の手法では、制御システムアプリケーションを実装できる自己記述的モジュールの使用、そして、言語と自己記述的モジュールを利用して実用的なソリューションを計算ノードに配置できるオーケストレータについてさらに説明する。
以下の手法は、本明細書で説明するＳＤＩＳ環境でのオーケストレーションの拡張実装のために、特に自己構成および自己記述的モジュールの使用を可能にする。本明細書で説明する自己記述的モジュールは、配置に必要なプラットフォームリソースの理解をより深めることを可能にし、要件や制約を明確にすることでオーケストレーションが容易になる。自己記述的モジュールは、エンドツーエンドアプリケーションの自己記述からの、モジュールの自己記述の分離をもたらす。自己記述的モジュールは、特定のソフトウェアモジュールの複数の代替実装を表現する機能と、実装間のトレードオフを行う機能も提供する。このような手法は、モジュールとアプリケーションの代替実装間のトレードオフを自動的に評価するアーキテクチャに実装できるため、ユーザがＩＡ（命令アーキテクチャ、例えば、ｘ８６、ＡＲＭ）上の最適化されたアプリケーションをオーケストレートするのに役立つ。
次の例では、モジュールはオーケストレータが配置するアプリケーションのコンポーネントである。モジュールは、その入出力、要件、およびその他のものを記述するモジュールマニフェストを有する（図１３に示され、表１の例で参照されている）。アプリケーションは、入力と出力が一緒に接続されたモジュールのコレクションで構成されている。アプリケーションは、アプリケーション仕様を使用して記述される（図２６に示され、表２の例で参照されている）。例では、このアプリケーション仕様は、エンドツーエンドアプリケーションを定義するためにユーザによって作成される。アプリケーション仕様は、適用可能なモジュールマニフェストとともに、オーケストレータへの入力を提供する。また、アプリケーション仕様を使用して、モジュール、それらの相互接続、およびそれらのモジュールの配置で満たす必要がある追加の要件を指定することもできる。したがって、このようにモジュールマニフェストおよびアプリケーション仕様を使用すると、エンドツーエンドのアプリケーションの機能オペレーションを実現および実装できる。
アプリケーションの配置のためにエンドツーエンドのアプリケーションを定義するという概念は、多くの設定で試みられている。ただし、オーケストレーションのこれまでの手法はＩＴの考慮事項に焦点を当てており、産業システムで使用するための柔軟な手法を提供していない。このような手法では、エッジデバイスからクラウド配置まですべてを包含するエンドツーエンドのアプリケーションは検討されない。さらに、以前のオーケストレーションシステムは、ユーザが特定のソフトウェアモジュールの代替実装を表現することを可能にしていなかったか、ユーザが代替実装間のトレードオフを評価または表現する手段を提供していなかった。次の自己記述的モジュールおよび自己記述的言語は、配置に必要なプラットフォームリソースの理解をより深めることを可能にし、適切な要件または制約を明確にすることで、オーケストレーションがより容易かつ正確になる。
例では、制御システムアプリケーションを実装できる自己記述的モジュールに加えて、ＳＤＩＳ実装を拡張して、制御システムアプリケーションが記述されている言語を提供し得る。これらの２つの要素から、オーケストレータは作業ソリューションをそれぞれの計算ノードおよびリソースに配置できる。したがって、本明細書で説明する技術は、（１）オーケストレーション可能なモジュールの自己記述を構築して、エンドツーエンドアプリケーションを個々のモジュールから分離し、（２）配置するモジュールの代替実装間をシステムが動的に選択できるようにし、（３）様々な状況でどの代替案が最適であるかをシステムが推論できるようにするためのメカニズムを提供する。
図２６は、センサおよびアクチュエータのレベルで表される例示的な制御アプリケーショングラフ２６００によって表されるような制御アプリケーションの概要を示す。示されているように、制御アプリケーションは、制御エンジニアによってソフトウェアモジュールのグラフとして定義され、各モジュールの出力（例えば、センサＡ ２６１０およびセンサＢ ２６２０からの出力）は、他のモジュールの入力（例えば、アクチュエータＣ ２６４０、およびＰＩＤコントローラ２６３０への入力）に接続されている。制御エンジニアは、モジュールパラメータの開始値など、他の要素も指定できる。制御エンジニアは、ソフトウェアライブラリでこれらのソフトウェアモジュールを見つけたり、ＩＴ部門によるカスタムモジュールの実装を要求したりできる。例では、このグラフは、グラフィカルユーザインタフェースまたは他の視覚に基づく表現を使用して定義され得る。例えば、例示的な制御アプリケーショングラフ２６００は、産業システムの入力、出力、およびコントローラを反映するように制御エンジニアによって定義され得る。例示的な制御アプリケーショングラフ２６００は、物理システムの接続を反映し、制御アプリケーションの様々な機能オペレーション（および実際の変化、測定、および効果）を実現するために使用され得る。
図２７は、図２６に示される制御システムモジュール（ＰＩＤコントローラ２７１０）などの自己記述的制御アプリケーションの実装のための例示的なソフトウェアモジュール定義を示す。例では、このソフトウェアモジュールのコードは、モジュールが配置されるノードを認識していないことや、モジュールが一連の名前付きインタフェースを介して隣接モジュールと通信できることを含め、いくつかの前提で書き込まれている。インタフェースは、接続指向のプロトコル（多くの場合、クライアントとサーバのエンドポイントを有する）を可能にする方向性を有することができ、これらは、多くの場合方向性のある方法で確立されるが、必ずしもデータフローの方向を指しているわけではない（どちらかまたは両方の方向に流れ得る）。
さらなる例では、このモジュールのコードは、それが隣接モジュール（帯域幅、レイテンシ、ジッターなど）と通信するチャネルの要件（例えば、ネットワーク要件２７４０）を有している。ただし、モジュールは、どのモジュールと通信するのか、またはそれらのモジュールがどのノードに配置されるのかを認識していない。モジュールは、その通信エンドポイントまたは他の通信エンドポイントの通信パラメータを認識していない。モジュールは、特定の量／種類の処理リソース、メモリリソース、およびストレージリソースを必要とする場合があり、他のハードウェアおよびソフトウェアの依存性（ライブラリ、命令セット、チップセット、セキュリティコプロセッサ、ＦＰＧＡなど）を必要とする場合がある。さらに、モジュールは、一連の名前付きの開始パラメータ（例えば、パラメータ２７２０）を指定できるようにし得る。
このコードを自己記述的にするために、モジュール開発者は、ソフトウェアモジュールで使用するためのモジュールマニフェストを作成し得、モジュールマニフェストを使用して、ソフトウェアモジュールの実行のための制御環境の重要な特性を識別および記述する。例では、特性は、（ａ）各インタフェースの名前、タイプ（クライアント、サーバ、パブ／サブ）、プロトコル（ｄｄｓ、ｏｐｃ−ｕａ、ｈｔｔｐ）またはＱｏＳ要件（ある場合）を含む（ＰＩＤコントローラ２７１０の）通信インタフェース、（ｂ）パラメータおよびデフォルトの開始値（例えば、制御パラメータ２７２０）、（ｃ）プラットフォーム要件（例えば、命令セット、ＯＳ、ＲＡＭ、ストレージ、処理）（例えば、要件２７５０）、（ｄ）依存性（例えば、ライブラリ、ハードウェア、入力信号など）（例えば、依存性２７３０）、（ｅ）配置要件（セキュリティ、分離、プライバシー、オーケストレーションスタイル）、または（ｆ）コードモジュールの署名（例えば、署名２７６０）などの機能を含み得る。
制御システムアプリケーションのモジュールマニフェストの例および図２７で実行されるモジュールは、次の定義で表すことができる。
［テーブル１］
［テーブル１］
さらなる例では、制御エンジニアは、１つまたは複数のソフトウェアモジュールのライブラリを利用して、制御システムアプリケーションを作成または定義し得る。例えば、グラフィカルユーザインタフェース（ＧＵＩ）を使用して、制御システムアプリケーションのグラフを設計し得る（例えば、図２６に示される制御アプリケーショングラフと同様）。ＧＵＩは、モジュールマニフェストを利用して、各コードモジュールの詳細を示し、それぞれのコードモジュールが相互にどのように接続され得るかを示し得る。さらに、ユーザは、ドラッグアンドドロップおよび他のグラフィック表示方法を利用して、適切なモジュールを選択し、それらを接続および構成して、図２６に示される制御アプリケーショングラフと類似のグラフを設計し得る。
制御システムアプリケーションのアプリケーション仕様にコンパイルされたこの情報の結果は、次の例に似ているアプリケーション仕様形式にエンコードできる。
［テーブル２］
［テーブル２］
この方法で定義されたアプリケーション仕様により、制御エンジニアは、使用する一連のモジュールを選択し、任意のデフォルト値を超えるパラメータの値を指定し、モジュール自体が指定するものを超える任意の追加の制約またはリソースを指定し、モジュールが一緒にリンクされる方法を指定できる。さらに、アプリケーション仕様では、トピック名をパブリッシュ／サブスクライブチャネルに割り当てたり、ポート番号をサーバエンドポイントに割り当てたり（通信エンドポイントをアプリケーションの外部からアクセス可能にする）など、特定のパラメータをリンクに割り当て得る。
例では、アプリケーション仕様は、（例えば、機能の各バージョンが異なるモジュールによって実装される）アプリケーション内の同じ機能の代替実装を指定することもできる。例えば、２つの異なるハードウェアアーキテクチャに同じ機能を実装するモジュールの２つのバージョンを考えてみる。モジュール作成者は、次の例に示すように、モジュールマニフェストでこれらの選択肢を指定できる。
［テーブル３］
［テーブル３］
別の例では、制御エンジニアは、次のようにアプリケーション仕様でこれらの選択肢を指定できる。
［テーブル４］
［テーブル４］
この例では、オーケストレータは、適切なソフトウェアモジュール実装を選択することにより、これらの２つの制約のいずれかを満たすこれら２つのアーキテクチャ（ｘ８６またはＡＲＭ）のいずれかのノードに配置できる。
自己記述的モジュール特性化の使用は、他の種類またはタイプのリソースに適用できる。例えば、アルゴリズムを汎用ＣＰＵ、ＧＰＵ、またはＦＰＧＡに実装できる場合は、このような自己記述的特性化を適用できる。この場合、アプリまたはモジュールの仕様でスコアリングを提供して、どのモジュールが好ましいかを示すこともできる。スコアリングは、アルゴリズム固有とデータ／アプリケーション固有の両方であり得るため、開発者または制御エンジニアに代わってある程度の知識が必要である。さらに、利用可能であれば、スコアリングを使用すると、特定のＩＡハードウェアプラットフォーム（例えば、ＦＰＧＡまたはニューラルネットワークプロセッサ（ＮＮＰ））向けに最適化されたソフトウェアモジュールを利用して、制御エンジニアが選択した制御アプリケーションを最適化できるようになり得る。
自己記述的モジュール特性化の使用は、より一般的なリソースを検討するためにさらに一般化され得る。例えば、アルゴリズムの第１バージョンはメモリリソース用に最適化され、一方、アルゴリズムの第２バージョンはストレージリソース用に最適化され得る。このシナリオでは、第１バージョンには小さなメモリリソース要件と大きなストレージ要件があるが、第２バージョンには大きなメモリリソース要件と小さなストレージ要件がある。オーケストレータは、使用可能な一連のノードで使用可能なリソースに基づいてモジュールを選択できる。さらに、スコアリングは、他の要素が制約されていない場合に、どのモジュールが好ましいかを判断するのに役立ち得る。
ノードアフィニティの場合、自己記述的特性化の使用も適用できる。例えば、モジュールＡがノードＡに優先レベルＮで配置され、一方、モジュールＢがノードＢに優先レベルＭで配置されるケース。ＮがＭよりも優先度が高いことを示す場合、システムは、モジュールＡが使用可能な場合はノードＡに、そうでない場合はモジュールＢをノードＢに配置しようとする。
ただし、自己記述的特性化の課題の１つは、制御エンジニアは、特定のソフトウェアモジュールのどのバージョンが、特定のアプリケーション機能を最も効果的に実行し、またはソフトウェアモジュールでどの基準を使用して最良のエンドツーエンドの結果を生成できるかさえ実際には知り得ない。制御エンジニアは客観的な結果のみを観察できる（例えば、どのソリューションが「最も応答性が高いと思われるか」）。ソフトウェアモジュール、基準、およびオプションの多くの組み合わせにより、フレームワークは、システムモジュールと代替実装の組み合わせが効果的かどうかをテストするために使用され得る。
図２８は、ソフトウェアモジュールの代替実装の自動評価のためのアーキテクチャを示す。具体的には、図２８のアーキテクチャは、アプリケーション仕様からモジュールの様々な組み合わせをエミュレートし、結果を特徴付けるためのフレームワークを提供する。ユーザのアプリケーション仕様とモジュールマニフェスト２８２０からの様々なデータがシステムに提供される。システムは、モジュールイメージリポジトリ２８１０に保存されているすべてのモジュールイメージにアクセスし得る。各モジュールのいくつかの代替実装があり得る。
例では、一連の実験が実行され、これらの実装の様々な組み合わせで評価される。実験は、様々な組み合わせが実行されることを保証する特性化コントローラ２８３０によって制御され得る。実験はオーケストレータ２８４０で機能する。オーケストレータは、アプリケーション仕様およびモジュールマニフェスト２８２０で指定されたモジュールを一連のエミュレータ２８５０に配置することを担当する。エミュレータ２８５０は、アプリケーション仕様またはモジュールマニフェスト２８２０（例えば、特定の量の使用可能なメモリを備えた特定のＦＰＧＡまたはＣＰＵ）で指定された特定の代替によって定義されたハードウェアをシミュレートする。オーケストレータ２８４０はアプリを配置し、コンポーネントを相互接続し、アプリを実行する。次に、システムは、スコアリング２８６０を使用して、いくつかの基準（例えば、エンドツーエンドレイテンシ）に基づいてシステムを自動的にスコアリングするか、またはユーザが主観的基準（「きびきびと感じる」）に基づいてアプリをスコアリングする。最後に、システムは様々な組み合わせについて推論し、決定ツリーに基づく手法を利用するなどして、使用する最適な組み合わせを決定する。
図２９は、図２８に示される例に加えて、ソフトウェアモジュールの代替の実装を評価するための例示的な方法のフローチャート２９００を示す。フローチャート２９００において、オプションの前提条件は、アプリケーション仕様およびモジュールマニフェスト情報を使用して、システム内で動作可能であるとしてアプリケーションおよびモジュールの構成を決定するオペレーションを含む（オペレーション２９１０）。この前提条件は、１回限りのイベントとして、または繰り返し実行できる。
フローチャート２９００のオペレーションは、特性化コントローラを介してそれぞれのオーケストレーションシナリオの定義および実行を続行し（オペレーション２９２０）、これは、シミュレーター（例えば、特定のハードウェア設定に従って構成されたエミュレータ）で１つまたは複数の定義されたオプションを使用してアプリケーションモジュールを実行するために使用される（オペレーション２９３０）。シミュレーターを使用すると、シミュレーターまたは別のシミュレーター構成で１つまたは複数の定義されたオプションを有する代替アプリケーションモジュールの使用を含む、様々なモジュールおよび様々なモジュールオプションを実行できる（オペレーション２９４０）。代替のアプリケーションモジュールの実行は、複数の様々なソフトウェアモジュールおよび複数のオプションについて繰り返すことができる。
フローチャート２９００のオペレーションは、定義された性能メトリックまたは基準に基づいて、アプリケーションモジュール実行の結果の評価を継続する（オペレーション２９５０）。１つまたは複数のアプリケーションモジュールの実行シナリオは、次いで、自動化された、または人間の影響を受けたスコアリングプロセスを使用して、スコアリング（オペレーション２９６０）、ランク付け、またはさらに評価される。スコアに基づいて、アプリケーションモジュールの様々な実行シナリオを組み込んだり更新したりできる（オペレーション２９７０）。
図３０Ａは、自己記述的オーケストレーション可能なソフトウェアモジュールを使用してアプリケーションを定義するための例示的な方法のフローチャート３０００Ａを示す。この方法は、アプリケーションオーケストレーションの一部として選択および利用されるソフトウェアモジュールまたはアプリケーション機能を定義するオペレーションから始まる。これらのオペレーションは、モジュールマニフェストの作成（オペレーション３０１０Ａ）を含み、モジュールマニフェストを使用して、制御システムアプリケーション（例えば、ＳＤＩＳの産業制御アプリケーション）のモジュールのオーケストレートされた実行のそれぞれの特性を記述する。さらなるモジュール定義オペレーションは、様々なソフトウェアモジュールのオペレーションのためのそれぞれのオプションおよび代替物の定義（オペレーション３０２０Ａ）、および様々なソフトウェアモジュールのオペレーションのためのリソース基準の定義（オペレーション３０３０Ａ）も含む。オペレーションは、それぞれのソフトウェアモジュールの定義に基づくアプリケーションの仕様の定義（オペレーション３０４０Ａ）、およびそれぞれのソフトウェアモジュール内で使用可能な機能の接続要件と条件も含む。このような定義は、図２６から２８を参照して上で論じた様々なオペレーションを含み得る。
フローチャート３０００Ａは、図２９を参照して上述したように、１つまたは複数のシュミレーションされたアプリケーション設定（オペレーション３０５０Ａ）などにおける様々なソフトウェアモジュールのエミュレーションおよび評価を続ける。エミュレーションの出力は、モジュールの様々な実装の優先順位または他の属性を含み得る。この評価から、このようなソフトウェアモジュールの実行のためのソフトウェアモジュールおよびオプション（優先順位、およびその他の属性）の特定の組み合わせを選択でき（オペレーション３０６０Ａ）、これらの組み合わせをオーケストレートされたアプリケーション設定に配置できる（オペレーション３０７０Ａ）。このような優先順位およびオプションは、物理システムの制約と特性と組み合わせた場合に、オーケストレーションプロセスに通知するために使用され得る。
図３０Ｂは、ＳＤＩＳシステム実装において自己記述的オーケストレーション可能なソフトウェアモジュールを使用するための例示的な方法のフローチャート３０００Ｂを示す。例では、フローチャート３０００Ｂのオペレーションは、制御システム環境内の複数の実行デバイスに動作可能に結合されてソフトウェアモジュールを実行するオーケストレーションデバイス（オーケストレータ）のために、オーケストレーションデバイスによって実行される。この構成により、少なくとも１つの実行デバイスを介して選択されたソフトウェアモジュールの実行は、制御システム環境における１つまたは複数の制御デバイスの機能オペレーションをもたらす。さらに、オーケストレーションデバイス（オーケストレータ）は、選択されたソフトウェアモジュールの実行を制御システム環境内のオーケストレーション制御戦略と連携させることができる。
フローチャート３０００Ｂは、モジュールマニフェストを作成するためのオプションの前提条件と、必要なシステム特性をリストするアプリケーション仕様で３０１０Ｂから始まる。オペレーション３０１０Ｂは、手動で、または自動化／コンピュータ支援機能を介して実行され得る。このモジュールマニフェストは、ソフトウェアモジュールが制御システムアプリケーションを実行するための環境を定義するために、次のプロセスで使用される。
フローチャート３０００Ｂはまた、一致するモジュール情報およびシステム特性（実行のためのパラメータ、値などを含む）を含む、制御システムアプリケーションのアプリケーション仕様を生成するためのオプションの前提条件で３０２０Ｂに続く。例えば、制御システムアプリケーションのアプリケーション仕様は、ソフトウェアモジュールまたは機能間の関連する接続または関係を示すことを含む、選択されたソフトウェアモジュールの制御パラメータの値を定義し得る。
フローチャート３０００Ｂは、使用可能なソフトウェアモジュールを識別するために３０３０Ｂに続き、モジュールマニフェストから制御システムまたは制御システム環境の特性を識別するために３０４０Ｂに続く。例では、制御システム環境で特定の機能オペレーションを実行できる使用可能なソフトウェアモジュールの動作態様が識別される。モジュールマニフェストで識別されるシステムの動作特性は、通信インタフェース、開始パラメータ、プラットフォーム要件、依存性、配置要件、または署名のうちの１つまたは複数に関連し得る。
フローチャート３０００Ｂは、使用可能なソフトウェアモジュールおよびシステム特性に基づいて１つまたは複数の一致するソフトウェアモジュールを選択するオペレーションで３０５０Ｂに続く。例えば、この選択は、使用可能なソフトウェアモジュールの動作態様と、モジュールマニフェストに示されているシステムの識別された動作特性との一致に基づき得る。
フローチャート３０００Ｂは、アプリケーション仕様の値および特性に従って、関連するソフトウェアモジュールの実行を含む、制御システムアプリケーションを実行するオペレーションで３０６０Ｂで終了する。最後に、フローチャート３０００Ｂは、関連するソフトウェアモジュールの実行（またはシュミレーションされた実行）の評価を可能にする３０７０Ｂでのオペレーションを含み、それにより、マニフェストまたはアプリケーション仕様のさらなるオーケストレーションおよびフィードバックが可能になる。例えば、評価は、少なくとも２つの異なるハードウェアアーキテクチャを使用して、選択されたソフトウェアモジュールの制御システム環境での実行を評価する段階と、少なくとも２つの異なるハードウェアアーキテクチャで実行されたオペレーションの効率測定を実行する段階とを含み得る。他のタイプの実行特性または配置も評価され得る。
様々な例において、制御システムアプリケーションは、グラフィカルユーザインタフェースに表示される視覚表現を使用して表示および修正され得る。例えば、視覚表現は、１つまたは複数のセンサ、アクチュエータ、またはコントローラの使用を含む入力または出力を含む、制御システムアプリケーションへの１つまたは複数の入力または出力の関係を確立するために使用され得る。
［センサバスの冗長性］
［センサバスの冗長性］
センサバスには、分散型制御システムでの多層フィールドデバイスの冗長性の使用など、冗長性があり得る。従来の産業制御システムは、工場のオペレーションを制御するための重要な要素としてプログラマブルロジックコントローラ（ＰＬＣ）を実装している。単一ＰＬＣが数百のフィールドデバイスと通信して制御し、比例、積分、微分コントローラなどの制御アルゴリズムを実行し得る。ＰＬＣの統合された性質により、ＰＬＣが故障すると、すべてのダウンストリームフィールドデバイスからのデータが使用できなくなり、ＰＬＣで実行されている制御機能が停止する。産業制御システムの完全な復元力を可能にする簡単な方法は、完全に冗長な環境を配置することである。ただし、すべてを２つ購入することはコストがかかり、多くの物流上の課題を引き起こす。
本明細書で説明するシステムおよび方法では、物理的および機能要件を切り離し、拡張性を向上させ、可能な産業アーキテクチャを拡張し得るフィールドデバイス抽象化バス（例えば、イーサネット）が使用される。
製造プロセスの信頼性および存続性を解決する。フィールドデバイス抽象化バスを使用すると、分散型制御環境内の任意の有線コントローラノードが任意の有線フィールドデバイスと通信できる。この「任意から任意」制御アーキテクチャは、正常な制御ノードが、故障した制御ノードの取得と制御の責任を引き受けることができるようにすることで、存続性を向上させ得る。正常な制御ノードは、存続性を改善するためにシステムに挿入された、既存の制御責任を有する制御ノードまたは「余剰」制御ノードであり得る。
データ可用性の拡大。既存のシステムは、多くの場合、独自仕様であり、密結合機能を実装しているが、相互運用性の制限により、データが自由に利用可能になることはあまりない。フィールドデバイス抽象化バスの実装により、生のフィールドデータが任意の認証済みの使用者に利用可能になる。
以前のソリューションおよびアーキテクチャは、機能を密結合された単一デバイスに統合することに焦点を当てており、「単一故障点」の問題を悪化させていた。したがって、フィールドデバイスのデータは、物理的なものであろうと仮想的なものであろうと「バス」上に置かれない。ホストコンピュータ（ＰＬＣ）のみがリアルタイムのフィールドデバイスデータにアクセスでき、ホストコンピュータ（ＰＬＣ）が故障した場合、ダウンストリームのフィールドデバイスデータにアクセスできない。
本明細書で説明されるシステムおよび方法は、コントローラとフィールドデバイスの「任意から任意」の関係を可能にする多層フィールドデバイス冗長バスを含む。コントローラとＩＯの分離により、単純なフェイルオーバーおよび冗長性が可能になる。
コントローラが故障した場合に任意のコントローラが任意のフィールドデバイスにアクセスできるようにすることで、システムの信頼性および存続性の向上が実現される。システムコストの削減は、ＰＬＣの重い負担の代わりに、わずかな追加投資に基づいて新しいフィールドデバイスを追加するなどの利点もあり得る。
図３１は、例による、ＰＬＣに基づく産業制御システムを示す。
本明細書に説明されている多層フィールドデバイスバス（ＭＬＦＤＢ）の利点は、プログラマブルロジック制御（ＰＬＣ）に基づく単純化された従来の配置と比較することで理解できる。制御戦略を実装する最も一般的な方法は、図３１に示すように、制御機能、ＩＯインタフェース、およびネットワークアクセスを単一デバイスに統合するＰＬＣを使用する方法である。単一ＰＬＣは拡張性が高いため、ユーザは多くのＩＯモジュールをプラグインして、制御システムのフィールドデバイスの数を拡張できる。ＰＬＣは何十年にもわたって産業制御システム市場に貢献してきたが、この手法にはいくつかの制限がある。まず、ＰＬＣが動作不能になると、フィールドデバイスや制御機能へのアクセスができなくなる。信頼性のために、業界は２つのＰＬＣと各フィールドデバイスを２つ購入することでこれを解決する。ただし、この冗長性の方法は、サイズ、お金および電力の観点からコストがかかる。第２に、新しいＰＬＣが必要な場合があるため、インフラストラクチャに少しずつ変更を加えると、多額の投資が必要な場合がある。図３１において、各ＰＬＣには、ｙ個のＩＯモジュールがあり、ｙは有限数である。ｙの値はＰＬＣベンダー／モデルに基づき得、例えば５から１００の範囲であり得る。
図３２は、例による、多層フィールドデバイスバス（ＭＬＦＤＢ）を示す。
ＭＬＦＤＢは、制御機能がフィールドデバイスＩＯから完全に切り離されているという点で、従来のＰＬＣに基づく配置とは異なる。図３２を参照してください。制御機能とＩＯの分離により、コントローラとＩＯの「任意から任意」の関係が可能になる。これは、システムの信頼性を高めるための重要な機能である。図３２は、制御機能の各々が、接続されたフィールドデバイスのいずれかから来るデータにアクセスでき、同様に、各制御機能が、接続されたフィールドデバイスのいずれかを制御できることを示す。この「任意から任意」の関係により、制御機能のフェイルオーバーが組み込まれ、システムの信頼性が向上する。例えば、制御機能１がフィールドデバイス２（レベルセンサ）からデータを読み取り、計算を行い、フィールドデバイス１（ポンプ）への出力値をオーケストレートすると仮定する。制御機能１をホストしているデバイスが故障した場合、制御機能１のプロセスは、フィールドデバイスバスにアクセスする別のデバイスで実行され得る。これは、フィールドデバイスがフィールドデバイスバス上で引き続きアクセスできるために可能である。
図３３は、例によるＩＯコンバータ機能を示す。
フィールドデバイスバスは、ＩＯコンバータを含む。ＩＯコンバータは個別にアドレス可能なデバイスで、フィールドデバイスＩＯをフィールドデバイスバスのプロトコルに変換する。図３２に示すように、各フィールドデバイスに直接取り付けられている物理的に小さく、信頼性の高いＩＯコンバータがある。ＩＯコンバータの数量は１からｎの範囲であり得、ｎはオペレーションの物理環境によって制約される。スタックビューでのＩＯコンバータ機能の高レベルのビューを図３３に示す。
ＩＯコンバータは、次の機能を担当する。
フィールドデバイスへの電気的インタフェース、ＩＯコンバータからフィールドデバイスへのインタフェースは、４〜２０ｍＡアナログ入力／アナログ出力、２４ＶＤＣデジタルＩＯ、シリアルインタフェース、またはイーサネットに基づくプロトコルの何れかであり得る。このインタフェースのこの設計実装は、ＩＯコンバータのＳＫＵを決定できる。例えば、ＩＯコンバータＳＫＵ１は、４〜２０ｍＡのアナログ出力またはアナログ入力であり得る。ＳＫＵ２は、高電流リレーの不連続出力になり得る。
フィールドデバイスプロトコル、この機能は、コマンド、制御、およびデータを、ダウンストリームフィールドデバイスとの通信に必要な適切な形式にエンコード／デコードする。例えば、ダウンストリームフィールドデバイスがＭｏｄｂｕｓスレーブであると仮定する。この機能は、Ｍｏｄｂｕｓプロトコルに準拠したＲＥＡＤ要求をエンコードし、フィールドデバイスに要求を送信する。
抽象化、抽象化機能は、フィールドデバイスに固有のコマンドとデータを人間が読める形式（データモデルで定義されている）に変換する。例えば、ＩＯコンバータが４〜２０ｍＡのアナログインタフェースを介して通信するＰＵＭＰに接続されており、制御システムが流量を１０ＧＰＭに設定したいとする。この機能は、１０ＧＰＭ要求を電流セットポイントから対応するミリアンペア値に変換する。逆に、フィールドデバイス固有の形式でフィールドデバイスからデータが送信される場合。
情報モデル化、この機能は、システムオペレータ（例えば、Ｈａｙｓｔａｃｋ）によって定義されたスキーマごとにデータをモデル化する。
フィールドデバイスバスプロトコル層は、モデル化されたデータを転送するための業界プロトコルに準拠し得る。例えば、データ配信サービス（ＤＤＳ）、ＯＰＣＵＡ、またはプロフィネットプロトコル。
フィールドデバイスバスへの電気的インタフェース。電気的インタフェースは、イーサネット、ＰＣＩ、プロフィネット、独自のバス技術などを含み得る。
提供機能、層は、ダウンストリームフィールドデバイスのアイデンティティを検出する発見層である。検出サービスは、ネイティブのフィールドデバイスプロトコル（例えば、ＨＡＲＴ）に組み込まれ得るか、追加の発見サービスとして追加する必要がある場合がある。どちらの方法でも、提供層は、下流に接続されたフィールドデバイスのアイデンティティを表す。
動作モードおよびリソースステータス層は、正常性とステータスのオーケストレーションシステムへの報告を担当する。正常性およびステータスのデータは、ローカルリソースの使用率、作業負荷の状態、一意のモジュール属性およびオペレーションモードを含む。
ローカルリソースの使用率の例は、信頼性の高いオペレーションであるＣＰＵの負荷、メモリの使用率、ストレージ、ページミス、エラーなどであり得る。
作業負荷の状態は、実行中のプロセスのステータスと正常性をキャプチャする。クラッシュしたプロセスは、オーケストレーションシステムがフェイルオーバー状態を開始し得るアラームをトリガーし得る。
一意のモジュール属性は、ＩＯコンバータの一意の識別子（ハードウェアに基づき得る）、ＩＰアドレス、ＭＡＣアドレス、または証明書などのアーティファクトで構成される。
動作モードとは、冗長システムにおけるＩＯコンバータの役割を指す。例えば、ＩＯコンバータをホットスタンバイモードに配置したり、プライマリモードに配置したりできる。さらに、ＩＯコンバータは、ピアＩＯコンバータをフィールドデバイスに物理的に接続できるようにするなど、フィールドデバイスからそれ自体を電気的に分離するモードに配置できる。
エージェント、ＩＯコンバータに常駐するエージェントは、様々なＩＯコンバータ機能の構成パラメータを仲介する。
図３２または図３３に示すフィールドデバイスバスは特定のバス技術に固有のものではなく、多くの異なる技術でインスタンス化され得る。例えば、イーサネットは、産業制御システム空間で増加するイーサネットに基づくデバイスの普及に基づいて使用され得る。イーサネットに基づくフィールドデバイス抽象化バスには、フィールドデバイスの幅広いシステムへのアクセス性を向上させるという利点がある。ただし、信頼性および確定性を維持するために、イーサネットに基づくフィールドデバイス抽象化バスには、時間依存のネットワーキング（ＴＳＮ）の統合が必要な場合がある。ＴＳＮの統合により、イーサネットに基づくフィールドデバイス抽象化バスが、ＰｒｏｆｉｎｅｔまたはＥｔｈｅｒｃａｔに基づくシステムの信頼性および適時性に一致できるようになり得る。
図３４は、例による、ＩＯコンバータの冗長性を示す。
多層冗長性は、フィールドデバイスに直接接続されたＩＯコンバータが故障する状況に対処するために使用され得る。このシナリオを軽減するために、複数のＩＯコンバータがフィールドデバイスバスに追加され、図３４に示すように（マルチドロップ構成で）単一フィールドデバイスに物理的に配線される。各ＩＯコンバータには１〜ｘのスイッチ出力があり、一度に起動的に駆動できる出力は１つだけである。これにより、ＩＯコンバータモードコントローラによって制御されるＩＯコンバータの冗長性が有効になる。オーケストレーションシステムは、それに応じて出力のオン／オフを切り替える各ＩＯコンバータの正常性およびステータスを監視できる。ＩＯコンバータモードコントローラは、どのＩＯコンバータがどのフィールドデバイスを制御するかを変更し得る。
図３５Ａ〜３５Ｂは、例による、ＭＬＦＤＢを実装する方法のフローチャート３５００Ａ〜３５００Ｂを示す。
フローチャート３５００Ａは、ＩＯコンバータで、フィールドデバイス（例えば、センサ）からデータを受信するオペレーション３５１０を含む。フローチャート３５００Ａは、フィールドデバイスバスプロトコルに従ってフィールドデバイスからのデータを変換するオペレーション３５２０を含む。フローチャート３５００Ａは、変換されたデータをフィールドデバイス抽象化バスに送信するオペレーション３５３０を含む。フローチャート３５００Ａは、フィールドデバイス抽象化バスを介して制御デバイスから制御信号を受信するオペレーション３５４０を含む。フローチャート３５００Ａは、制御信号に基づいてフィールドデバイスに電気信号を送信するオペレーション３５５０を含む。
フローチャート３５００Ｂは、複数の対応するＩＯコンバータを介して複数のフィールドデバイス（例えば、センサ）からデータをセンサバスで受信するオペレーション３５６０を含む。フローチャート３５００Ｂは、１つまたは複数の制御機能にデータを送信するオペレーション３５６２を含む。フローチャート３５００Ｂは、データに基づいて１つまたは複数の制御機能から１つまたは複数の制御信号を受信するオペレーション３５６４を含む。フローチャート３５００Ｂは、１つまたは複数の制御信号を複数のＩＯコンバータのそれぞれのＩＯコンバータに送信するオペレーション３５６６を含む。フローチャート３５００Ｂは、ＩＯコンバータモードコントローラから情報を受信するためのオプションのオペレーション３５６８を含む。フローチャート３５００Ｂは、ＩＯコンバータモードコントローラから受信した情報に従ってフィールドデバイスへのＩＯコンバータの割り当てを容易にするためのオプションのオペレーション３５７０を含む。
［産業システムの動的アラーム］
［産業システムの動的アラーム］
産業制御システムは、監視モードで機械のオペレーション用ガードレールとしてアラームに大きく依存している。多くの場合、これらのアラームはシステムの人間の知識および理解に基づいて作成される。その結果、アラームは最適ではない。典型的なシステムは、システムの準最適または有害であると考えられるすべての条件に対して多くのアラームを備えた制御エンジニアによって開始される。例えば、特定の閾値を下回るまたは上回る電圧値に対してアラームが作成される。制御システムのアラームは、多くの場合、次の３つの理由のうちの１つで作成される。
・安全（人員および環境）
・機器の完全性
・品質管理
ただし、アラーム管理の問題の１つは、これらのアラームが人間によって作成され、多くの場合、重要ではない可能性があることを警告する傾向があることである。さらに悪いことに、同じ物理的な事件によって複数のアラームが生成され得るため、アラームは冗長であることがよくある。これは、アラーム洪水と呼ばれることがよくある。
現在のアラームシステムは、人間の生成および入力に大きく依存している。その結果、それらは過剰割り当てに苦しむ傾向がある。これは、大量のアラームが生成されるアラーム洪水の場合に簡単に見られ、工場の故障時に気が散ることがよくある。
既存のソリューションは、アラームを過剰に生成する傾向があり、これは危険であり、アラームの疲労につながり得る。このアラームの生成は、制御システムで問題のある状況を検出するための誤感知の過剰生成の結果である。アラームの結果として多数のイベントが発生する場合、これらのイベントを異常検出などの他のアプリケーションに使用するように設計された分析が過度に複雑になる可能性もある。
本明細書で説明されるシステムおよび方法は、スマート機械学習手法を使用してアラームを管理する。本明細書に説明されているシステムおよび方法は、以下であり得る。
アラームをトリガーし得る異常を検出するために、データを特徴付ける。
データの類似性または一般的な因果関係のいずれかを使用してアラームをクラスタ化し、その結果、アラームの洪水と疲労に対処するための１つのバンドルとして提示する。
または、将来のそれらの動作を自動化するために、アラームに対する人間の反応を理解する。
図３６は、例による、生成されたアラームを伴うプロセスの例を示す。
産業システムでは、データは多くの場合、様々なモジュールとセンサによって生成される。データは、アラーム生成の基礎となる。最も基本な形式では、アラームは、閾値を通過するセンサデータなどの条件に基づいて生成される。例えば、物理プロセスが電力メーターに接続されている場合、制御エンジニアは、機器が（まとめて）回路が処理できるよりも多くの電力を引き出すと、人間の介入のためにアラームが発生し得ることを知ることができる。アラームは、複数のレベルのエスカレーションを通過し得る。例えば、最初はアラームが発生するが、消費電力が増加し続けると、追加のアラームが生成され、システムの電源が遮断される。後者の場合は、プロセスを動作状態に復元するための生産性と工数の損失に関連するコストが発生し得るため、望ましくない場合がある。
アラームは連鎖的に影響し得る。例えば、最初のプロセスが停止する場合、工場のラインに沿った次のプロセスが停止し、次いで、１つまたは複数のアラームが発生し得る。突然、オペレータがアラーム洪水に遭遇し得る。彼らがどのアラームにどのように対応すべきかを決定することは、多くの場合、疲れる可能性があり、さらに分析と専門知識が必要になる場合がある。
本明細書で説明するシステムおよび方法は、機械学習を使用して、アラーム、クラスタラームを割り当てるか、応答動作を提案する。
図３６は、システムによって生成されたアラームの例を含む物理プロセスを示す。
これらのアラームは、次のデータフィールドのうちの１つまたは複数を含み得る。
・アラームのタイプ
・アラームを生成する物理プロセス
・アラームの重要度
・タイムスタンプ
・考えられるフラグまたはアラームの原因
・アラーム受信者としてフラグが付けられたユーザ
アラームをリセットまたは解決するために必要な可能な動作
データは中央の場所に送信され、次いで、ＨＭＩ画面、ユーザのモバイルデバイス、または分析と保管用のリポジトリにルーティングされ得る。
本明細書で説明されるシステムおよび方法では、ユーザはアラームを作成し得る。これらのアラーム構成は保存して分析できる。データ、コンテキスト、およびアラーム構成に基づいて、追加のアラーム推奨がユーザに提示され得る。例えば、電気メーターが工場の床にあることを示すメタデータを含むそのメーターに対してアラームが作成された場合である。
工場のメタデータ（および情報モデル）を使用して、これらの作成されたアラームおよび対応する物理デバイスとの類似性について他のデバイスが分析される。さらに、これらのデバイスによって生成されるデータのタイプと、アラームをトリガーし得るストリームは、類似のモジュールに供給される。
図３７は、例による動的スマートアラームを示す。
図３７のシステムは、データ署名マネージャと呼ばれることがあるデータプロファイラを含む。このモジュールは、機械学習を使用して、ストリームの類似性を判断し得る。これらの類似点のいくつかは、個々のストリームに基づくか、ストリーム間の相関関係に基づき得る。例えば、液面センサストリームは、類似の物理的プロセスから生成されている別の液面センサと同様に決定され得る。物理的なプロセスは、例えば、以下に基づいて同様に見なされ得る。
・物理プロセスのメタデータ
・同じ物理プロセスに関連付けられているストリームの数およびタイプ
・同じ物理プロセスの異なるストリーム間の相互相関
・または、異なるプロセスからのストリームのタイプと周波数の類似性
例えば、第１物理プロセスに２０ストリームがあり、そのうちの３つが液面で２つが液流であり、第２物理プロセスが２１つのストリームで３つの液面と２つの液流がある場合、次に、２つのストリームが類似のスケールで高くランク付けされ得る（液面と液流の数は同じで、１ストリームの違いのみ）。
データ署名マネージャは、その出力を動的スマートアラームシステムに供給する。動的スマートアラームシステムは、類似のシステムの既存のアラームに基づいてアラームをオーケストレートする必要がある潜在的なプロセスを識別するトリアージユニットとして機能する。
動的スマートアラームシステムは、次の３つのコンポーネントで構成され得る。
アラーム発生器、このモジュールでは、一部のプリアラームがデフォルトでプリロードまたは作成される。これらは、明示的に人間が作成し得るか、要件に基づき得る。例えば、特定の回路の消費電力が特定の閾値を超えることはない。このモジュールは、アラームの生成、編集、または削除を担当する。このモジュールは、データの類似性の出力を使用して、アラームを作成または提案するかどうかを決定する。それは、特定のアラームのニーズのスコアを作成し得る。スコアが非常に高い場合、アラーム発生器が自動的にアラームを作成し得る。ただし、スコアが中程度の場合、モジュールは、このようなアラームを作成する前に、例えば人間のオペレータ／専門家に入力を要求し得る。アラームに類似、関連、または独立のタグを付けるのも、アラーム発生器の役割である。このタグは、複数のアラームが生成されている場合に次のモジュールで使用される。
アラーム管理／クラスタ化、このモジュールは、アラーム間の関連付けを追跡する。それは、アラーム発生器で作成されたタグを使用し得る。実際のアラームからのデータを監視することにより、タグを拡張することもできる。アラーム管理は、相関または一連のイベントを検出するために、様々なアラーム出力を監視し得る。データに対して両方のタイプの分析を実行できる。
相関関係は、２つのイベントが高度に相関していること、およびそれらが一緒にクラスタ化され得ることを決定し得る。例えば、特定の物理プロセスには、様々なイベントを警告するために５つの異なるアラームがあり得る。ただし、ハード故障のためにシステムが停止している場合、すべてのアラームが同時にまたは短時間で起動し得る。次いで、これらのイベントは相関性が高く、クラスタ化してアラームの洪水および疲労を最小限に抑えることができる。モジュールは、コンポーネントのクラスタ化に意味のある理由を作成するために、アラームのメタデータとそれらがカバーしているシステムを使用することもできる。上記と同じ例を使用すると、５つの異なるアラームに物理プロセスのメタデータが関連付けられ得る。したがって、これら５つは「レベルタンクプロセス、２階、西、地域３」で折りたたむことができる。さらに、クラスタ化では、意味のある説明のためにアラーム自体のデータを使用し得る。
図３６は、アラームが含み得るものの例を示す。データが集計され得、結果に「レベル：重大、原因：電力が高すぎる」と表示され得る。このクラスタ化では、自然言語処理（ＮＬＰ）の技術を使用して、これらの意味のある説明を作成できる。説明の多くは人間が生成し得、同じ種類の故障を説明する場合は若干異なり得る。ＮＬＰは、わずかに異なるものをオーケストレーションまたはグループ化するために使用され得る。例では、アラームＸがシステムＹに転送することに気づき、次いで、システムＹがユーザにリセットを選択させた場合、アラームＸでリセットすることもできる。まず、図３７のシステムはゆっくりと進み得、Ｘの後にリセットすることを提案し、経時的に、尋ねずにリセットするだけである。
このモジュールは、アラームシーケンスを状態マシンとしてモデル化することもできる。例えば、モジュールは、プロセス１が失敗する場合、プロセス２で報告される失敗の確率が非常に高いことに気付き得る。遷移を表すエッジに確率が割り当てられた状態マシンを使用して一連のイベントがモデル化される予測メンテナンスでも、類似の技術を使用できる。これにより、システムが状態Ｓ１に到達し、Ｓ１とＳ２との間の遷移に高い確率のエッジがある場合、アルゴリズムは状態Ｓ２が発生し得ることを予測できる。この機能により、モジュールは別の一連のアラームが起動されることを予測でき、事前にユーザに通知する可能性がある。アラーム間の関係は、イベントの発生前または発生後に表示され得る。
アラーム出力マネージャ、このモジュールは、システムを自動オペレーションに移行するために使用される。最初は、このモジュールには、ポリシーも、何らかの簡単な書き写されたポリシーもなくてよい。それは、次に、アラームが生成されて処理される場合に、ユーザの動作を監視し得る。一連のアラームが無視される傾向にある場合、このモジュールは、これらのアラームが意味を持たないことを経時的に学習でき、潜在的に低い優先度が与えられるか、削除さえされる可能性がある。例では、削除は人間の承認なしには起こり得ない。さらに、モジュールは他のイベントを監視および記録できる。例えば、人間のオペレータは、アラームが発生した場合にいくつかの動作を試み得る。一連の動作は、パラメータの構成の変更、モジュールのリセット、システムの一部の再起動などを含み得る。このシーケンスは、例えば、アラーム出力マネージャを使用して、故障の特定の機能をさらに特徴づけたり、実際にシステムの再起動が必要であり、例えば、または単純なモジュールリセットを使用できると判断することで回避できる。また、システムへの信頼性が高まると、それだけでシステムがこれらの動作を取り得る。例では、最初に、オプションは人間のオペレータへの推奨として提示され得る。
図３８は、例による、動的アラーム制御のための方法のフローチャートを示す。フローチャート３８００は、産業制御システムの複数のアラームに関する情報を保存するオペレーション３８１０を含む。フローチャート３８００は、情報からの複数のアラームのデータ、コンテキスト、およびアラーム構成を分析するオペレーション３８２０を含む。フローチャート３８００は、複数のアラームのうちの１つまたは複数への変更を推奨するか、または新しいアラームを推奨するためのオプションのオペレーション３８３０を含む。フローチャート３８００は、情報からアラームストリームの類似性を決定するオペレーション３８４０を含む。フローチャート３８００は、２つまたはそれより多くのアラームでアラームイベントを検出するオペレーション３８５０を含む。フローチャート３８００は、２つまたはそれより多くのアラームが発行されるのを防ぐためのオペレーション３８６０を含む。フローチャート３８００は、発行されないようにされた２つまたはそれより多くのアラームに対してクラスタ化されたアラームを生成するオペレーション３８７０を含む。
［閉ループ制御オペレーションによる学習の自動統合の方法］
［閉ループ制御オペレーションによる学習の自動統合の方法］
自動学習方法の統合は、産業における現実的な制限のある実装で成長し続けており、ほとんどの前進はロボット工学と自動化された運転空間で行われている。ＩＴ−ＯＴ収束が実現し、モジュール式システムの柔軟性をさらに有効にするため、これらの開発技術と方法の将来を見据えた自動アプリケーションは、より広範な連続および不連続の製造業界に浸透する。ミッションクリティカルなオペレーションに価値を確認した新しいモデルを自動的に識別する機能、および確認済みの機能を自動的に配置する機能、ならびに信頼性を有する「閉ループ」は、ＩＥＣ６１１３１−３、ＩＥＣ−６１４９９、およびより高いレベルのＩＳＡ（Ｌ１−Ｌ３）制御システムドメインの製造企業に、新しいレベルの効率、コスト削減、および収益の価値をもたらす。
従来の閉ループ制御システムと自動学習技術の統合には、自動ワークフローをサポートする新しい弾性ソリューションアーキテクチャの作成方法が必要である。これらの方法はまた、自動的に配置された新しい閉ループ制御ソリューションアーキテクチャの推奨事項を本質的に生み出し、連続および不連続の製造オペレーションの両方で定義されたリファレンスアーキテクチャの境界内に収まる実現可能な実装について評価する必要がある。自動的に「ループを閉じる」このような自動システムは、安全性、品質、制約の識別、実装の実現可能性、値のスコアリング、自動化された監視、および実行可能なミッションクリティカルなシステム配置のためのシステム管理統合のためのリアルタイムのポリシー評価をサポートし得る。自立性は、純粋なソフトウェア統合を超えて拡張でき、計算、ストレージ、およびネットワーキングアセット全体にわたるハードウェアの選択を含む、エンドツーエンドシステム配置のすべての側面と統合できる。作成された特定の新しい制御アプリケーションの場合、自動的に配置された閉ループソリューションの安全で境界のあるオペレーションを保証するには、複数のサブシステムドメインにわたるリアルタイムの連携および確認が必要な場合がある。
ミッションクリティカルな環境で次の８段階のプロセスを通じて新しい閉ループ作業負荷の自動作成を管理するために、順次厳密なポリシーフレームワークと一連の方法を提示する。
・プロセスに対する新しいアルゴリズムの品質および感度の評価
・動作制約境界の自動化された設定
・既存のプロセスに対する新しいアルゴリズムの自動化された安全性評価
・幅広いプロセスのための自動化された価値評価
・制御環境での配置の実現可能性に関する自動化されたシステム評価
・新しいアプリケーション制御戦略の物理的な配置および監視
・ライフサイクル管理システムへの統合
・サポート終了処理への統合
８段階の処理のオペレーション順序は変更され得る。例えば、安全性評価は価値評価の後に行われ得る。
典型的な自動化システムは、制御戦略の実装に関しては非常に高度であるが、このようなシステムの弾力性が一般に存在しないレガシーシステム配置に本質的にロックされている。新しいシステムは、ＩＴシステムに見られるシステムの進歩を反映する新しいレベルの柔軟性と弾力性を有し得、今回のＩＴシステムもＯＴシステムも現在、このレベルの自動的インテリジェンスを備えていない。
一般に、分散型制御システムの設計空間に実装された以前のソリューションでは、高度なエンジニアリングの監視なしに、後続の実装と試運転（ループを閉じる）を伴う新しい制御戦略の任意のレベルを自動的に作成できない。さらに、今日の制御戦略の設計は自動的ではなく、高度なエンジニアリングが必要である。制御の実装は、リソースを集中的に使用するエンジニアリング作業でもある。ループを閉じてアルゴリズムをオーケストレートする試運転作業も、ハンドヘルドで高度に設計されたプロセスである。これらのタスクのいずれかを今日自動的に行うことは、実際には前代未聞である。
以前のソリューションは、既存のプロセスに関連して新しく作成されたアルゴリズムの自動化された一般的な安全性評価を作成する機能を利用できなかった。以前のソリューションは、既存のプロセスと比較して新しいアルゴリズムの自動化された品質および感度の評価を作成する機能を利用できなかった。以前のソリューションでは、動作上の制約境界の自動化された設定を作成する機能を利用できなかった。以前のソリューションでは、制御環境への配置の実現可能性に関する自動化されたシステム評価を作成する機能を利用できなかった。以前のソリューションでは、使用可能なデータに基づいて、より広範なプロセスの自動化された価値評価を作成する機能を利用できなかった。
以前のソリューションでは、新しい制御アプリケーションの自動化された物理的な配置および監視を作成する機能を利用できなかった。以前のソリューションは、既存の標準化されたライフサイクル管理システムへの自動化された統合を作成する機能を利用できなかった。以前のソリューションは、動的作業負荷の修正および移植性が不可能であるアプリケーションおよびデバイス固有の実装に固定され得ていた。以前のソリューションは、ハードウェアおよびソフトウェアに密接に結合され得る。以前のソリューションは、ほとんどの場合、法外に高価になり得る。以前のソリューションでは、カスタム割り込み管理を備えたカスタムハードウェアが必要な場合がある。以前のソリューションは、意思決定ツリーのルールセットの一部としての値イベントの予測による動的発見、シミュレーションおよび最適化を含み得ない。
ここでは、８段階によるミッションクリティカルな環境で新しい閉ループ作業負荷の自動作成を管理するための、順次厳密なポリシーフレームワークと一連の方法を提示する（以下のように命令されたり、他の命令で発生したり、同じ期間または重複していくつかの段階が発生し得る）。
・プロセスに対する新しいアルゴリズムの品質および感度の評価
・動作制約境界の自動化された設定
・既存のプロセスに対する新しいアルゴリズムの自動化された安全性評価
・幅広いプロセスのための自動化された価値評価
・制御環境での配置の実現可能性に関する自動化されたシステム評価
・新しいアプリケーション制御戦略の物理的な配置および監視
・ライフサイクル管理システムへの統合。
・サポート終了処理への統合
本明細書で説明するシステムおよび技術は、分散型アプリケーション制御戦略レベルで次の機能を提供する。
制御下にある既存の制御システム階層との全体的な学習システムオペレーション統合を可能にする。
制御下にある既存の動作プロセスに関連する新しいアルゴリズムの自動化された安全性評価を可能にする。
制御下にある既存の物理プロセスに関連する新しいアルゴリズムの品質および感度の評価を可能にする。
制御下のシステムの動作制約境界の自動化された設定を可能にする。
制御環境用に自動的に作成されたアプリケーションの配置の実現可能性の自動化されたシステム評価を可能にする。
制御下のより広範なプロセスの自動化された評価アセスメントを可能にして、自動的に作成された制御アルゴリズムの経済的効果を保証する。
自動的に作成された新しい制御アプリケーションに対して、自動的に物理的に配置して新しい監視を作成する機能を可能にする。
標準的なライフサイクル管理システムへの自動的な統合を可能にする。
継続的なＲＯＩ監視を通じて、サポート終了処理への統合を可能にする。
低コストのコモディティハードウェアおよびソフトウェアを進化させ、活用し続けて、制御戦略レベルでより優れたシステム性能を実現する。
自動機能が自動化構成に設計されている多くの保守タスクを自動的に実行できるようにする。
図３９は、自動制御学習統合フロー図を示す。
これらの８つの段階を通じて、ミッションクリティカルな環境で新しい閉ループ作業負荷の自動作成を管理するための、順次厳密なポリシーフレームワークおよび一連の方法をここに提示する（以下のように命令されたり、他の命令で発生したり、同じ期間または重複していくつかの段階が発生し得る）。
・プロセスに対する新しいアルゴリズムの品質および感度の評価
・動作制約境界の自動化された設定
・既存のプロセスに対する新しいアルゴリズムの自動化された安全性評価
・幅広いプロセスのための自動化された価値評価
・制御環境での配置の実現可能性に関する自動化されたシステム評価
・新しいアプリケーション制御戦略の物理的な配置および監視
・ライフサイクル管理システムへの統合
・サポート終了処理への統合
これらの８つの連続するプロセスの相互作用は以下に示され、各々は図３９により詳細に記載され、継続的な２４時間年中無休のミッションクリティカルなオペレーションをサポートするための基本的な反復フィードバック分析を備える。
Ａ．新しい学習アルゴリズムの作成
プロセスは、新しい学習アルゴリズムの作成から始まり得る。採用されている自動プロセスは、システムリソース、物理プロセス、および基本ＩＳＡレベル１制御（ＩＥＣ６１１３１−３／ＩＥＣ６１４９９−３機能ブロック、バイナリ、ラダーロジック、ＰＩＤなど）、制約および監視制御（Ｌ２／Ｌ３）、多変数モデル予測制御（Ｌ３）、生産スケジューリング（Ｌ３）、および計画システムアクセス（企業）を含む制御システムパラメータに関連するすべてのデータにシステム全体でアクセスできる。学習システムの範囲は、財務および会計、契約管理、および一般的な企業またはサプライチェーンのオペレーションに関連する従来とは異なるシステムアクセスを含み得る。有意な相関関係で作成されたアルゴリズムは、単純な小さなデータ指向の数学的ソリューション（総和、除算、乗算、ＰＩＤ、統計など）、第１原理に基づく自動モデル開発、経験に基づく自動モデル開発、ビッグデータ分析、機械学習やディープラーニングアルゴリズムなどを含む幅広いアルゴリズムファミリーをカバーし得、本開示は、生成され得るアルゴリズムの完全な環境を説明するものではない。このようなアルゴリズムは、データサイエンスの観点からは、自由に使用できる。
分析が段階Ａから段階Ｉに進むにつれて、合格および不合格のテストが自動的に作成および実行され、作成された新しい自動学習および制御ループを評価および確認する。反復プロセスは、合否分析をリアルタイムでサポートするために使用される。一部の段階は、順不同で実行され得る、同時に実行され得る、などである。
Ｂ．品質および感度の評価
重要度のモデルが段階Ａで自動的に発見されると、段階Ｂが呼び出され、作成されたアルゴリズムの初期品質および感度の評価が形成される。自動的な品質および感度の評価は、プロセスの最新のリアルタイムシミュレーションされたプロセスモデル（デジタルツイン）に依存している。シュミレーションされたプロセス範囲は、プロセス全体のサブセットであり得、バルブやポンプなどの小さなアイテムを含み得るか、制御下にあるプロセスユニット全体（製油所の原油ユニット、反応器、プラントのより広いセクション）をカバーし得る。この一般的な品質および感度の評価では、段階Ａで作成されたモデルを使用して、分散型制御システム内で起動的に使用されているシミュレーションされた物理プロセスおよび制御アルゴリズムにオーバーレイする。品質および感度の評価は、次いで、新しいモデルへの入力信号（ＰＲＢＳ、シュレーダー波など）を生成することにより、各独立したプロセス変数を実行し、シュミレーションされたプロセスとシステムに配置された有効制御戦略の依存プロセス変数への影響を経時的に追跡する。プロセス出力結果は、シュミレーションされたプロセスオペレーションでの新しいモデルの感度を考慮した品質評価プロファイルに対して、絶対的かつ統計的に測定される。
テストに合格した場合、モデル評価は段階Ｃに進む。テストが失敗した場合、結果は再評価するために学習システムに送り返される。
Ｃ．制約境界の識別
段階Ｂの結果を使用して、作成された新しいアルゴリズムのプロセス範囲の動作上の安全性、品質および感度の基準を包含しおよび実施する、作成された新しいモデルの制約境界を設定する。識別された新しい制約境界は、シミュレーション（例えば、ノイズの追加、摂動、システムが新しいモデルを使用してどのように反応するかの確認）および新しく生成された制約プロファイルと比較した結果を実行する。
テストがプロセスシミュレーションと関連する既存および新しい制御モデルの評価に合格した場合、評価は段階Ｄに進むことができる。テストが上記のいずれかの基準に失敗した場合、結果は再評価するために学習システムに送り返される。
Ｄ．安全性評価
段階Ｃで新しい一連の制約が識別されると、段階Ｄが呼び出され、作成されたアルゴリズムの初期安全性評価が形成される。段階Ｄは、新しい学習アルゴリズムを使用した閉ループオペレーションの物理プロセスに対する新しい学習アルゴリズムの相対的な影響の安全性評価をカバーしている。ここでは、モデルの作成中に段階Ａで確立された統計的品質に基づいてモデルＩ／Ｏにノイズを導入することにより、様々な条件でモデル品質が評価される。
自動安全性評価は、プロセスの最新のリアルタイムシミュレーションされたプロセスモデル（デジタルツイン）に依存している。シュミレーションされたプロセス範囲は、プロセス全体のサブセットであり得、バルブやポンプなどの小さなアイテムを含み得るか、制御下のプロセスユニット全体（製油所の原油ユニット、反応器、プラントのより広いセクション）をカバーし得る。この一般的な安全性評価は、段階Ａで作成されたモデルを使用し、分散型制御システム内で起動的に使用されているシュミレーションされた物理プロセスと制御アルゴリズムにオーバーレイし、段階Ｃで説明されているように制御システムに対して識別された新しい制約をオーバーレイする。次に、安全性評価は、新しいモデルへの入力信号（ＰＲＢＳ、シュレーダー波など）を生成することにより、独立した各プロセス変数を実行し、シミュレーションされたプロセス、システム内に配置された新しい制約および有効制御戦略の依存プロセス変数への影響を経時的に追跡する。次に、結果がプロセスの確立された安全性メトリックと比較され、合否スコアが決定される。
使用され得る可能性のある安全性チェックの範囲は幅広くあり、ここではカバーされていないが、通常安全なオペレーションでは超えられない流量、圧力、温度、ｒｐｍまたはその他の主要変数の重要なプロセス制約として現れ得る。これらのシステムに関連する変数への影響は一般的な安全性分析の対象と見なされ、実際のプロセスおよび制御シミュレーションに含まれ得るが、この分析は認定された機能的に安全なシステムと混同してはならない。
結果は、制御下の機器またはプロセスの安全プロファイルに対して測定される。アルゴリズムが製造オペレーションの機器またはプロセスフローのすべての安全性チェックに合格した場合、確認プロセスは段階Ｅに進むことができる。安全性チェックに失敗した場合、結果は自動学習アルゴリズムブロックに返され、重要なアルゴリズムの再評価および再作成が行われる。
Ｅ．価値評価
価値評価は、新しいモデルがプロセスセグメントに与える影響をローカルで自動的に評価するのと同様に、より広範なエンドツーエンドの製造プロセスを評価するために使用される。シュミレーションされたプロセス（デジタルツイン）および制御システムに対して境界制約が識別された場合、企業収益への閉ループ性能の影響のコンテキスト内での新しい学習アルゴリズムの評価は、新しい制御戦略を使用して履歴デジタルツインシミュレーション結果を再生することにより自動的に評価される。結果は、様々な価値基準を使用してベースライン性能と比較される。以下の表７に例を示す。
価値評価がオペレーションで指定された指定のＲＯＩおよびＮＰＶ基準を実現した場合、テストに合格し、評価は段階Ｆに進む。テストが失敗した場合、結果はさらに評価するために学習システムに送り返される。
Ｆ．配置の実現可能性
配置の実現可能性は、新しい作業負荷を配置し、アルゴリズムを分散型制御システムの既存の制御構造に統合するシステムの能力の観点から測定される。これは、以下の領域について厳密なリアルタイム評価が完了する場所である。
配置テストに合格すると、デジタルツインシミュレーションシステムへの実際の配置によって配置がテストされ、このシステムでは、トレーニングがオペレーションとともに自動的にスケジューリングされる。
自動化されたトレーニングシミュレータの配置およびコースのスケジューリングは以下の通りである。
ｉ．生成され、確認のためにオペレーションに送信される新しい制御ループの自動化されたトレーニングドキュメント。
ｉｉ．トレーニングスケジュールが確立され、オペレーションによって完了する。
Ｇ．物理的な配置および監視
制御システムに識別された新しい制約を使用して段階Ｆで物理的な配置および監視をテストすると、オペレーションによるトレーニングとサインオフが完了し、配置の新しい制御戦略が完了される。物理的な実装は、新しい機能ブロックの入出力構成と古い機能ブロックへの修正が指定されているシステムオーケストレータの管理に従って進行する。実現可能な自動配置の段階は次のとおりである。
オペレーションへのオンライン配置
１．手続き的に、すべての制御は、新しい制御システム機能の自動システムの実装および試運転のオペレーションによって事前に指定されているように、自動的に最低許容自動安定ループ構成に切断し得る。
２．使用可能なシステムリソース（計算、ストレージ、ネットワーキングなど）を利用して、定義されたシステム制約および監視構成内での新しい制御および学習モデルの物理的な配置が完了する。
３．自動化された試運転は、ライブＩ／Ｏが新しい制御ループに供給され、独立変数の新しい制御動作が指定された期間にわたって分析されて挙動が予想通り確認される「ウォームモード」で実行するように自動的に開始される新しいループで発生する。
４．オンライン確認テストが完了すると、新しいアルゴリズムのループが閉じ、新しい出力がダウンストリームのセットポイントに書き込まれ、オペレーションに通知が送信されてミッションクリティカルなプロセスが駆動される。
上記の４つの段階すべてで自動配置が成功した場合、システムは自動的にライフサイクルサービスに登録する。上記の４つの段階のいずれかでシステムの自動物理配置が失敗した場合、システムは以前の構成に戻り、結果が学習システムに送り返され、オペレーションは通知される。
Ｈ．ライフサイクルの統合
自動登録は、通常のオペレーションのために配置されたシステムの新しい制御ループおよび学習ループで行われる。
１．自動化されたスクリプトが生成、テスト、配置され、新しい制御アプリケーションがライフサイクル管理システムに登録される。
２．フィードバックループは、図３９に示されるように、品質、制約、安全性、価値、配置、およびライフサイクル性能の自動化されたメトリックに対して新しい制御アプリケーションを継続的に監視する。
監視されているメトリックのうちのいずれか１つが低下すると、現在実行中の制御戦略が制御学習評価ブロックに送り返され得たり、制限仕様の変更、チューニングパラメータの変更、配置の変更などが発生したりし得る。
Ｉ．サポート終了
フィードバックを使用して（図３９を参照）、経済的価値評価のメトリックに対する継続的なチェックにより、企業の動作価値の自動化された評価を推進できる。定義された基準を下回る値の低下により、サポート終了プロセスがトリガーされる。
サポート終了処理は自動化できるが、手動での確認に戻すオプションが望まれ、自動化された廃止措置につながるか、自動化の複雑さに応じて手動での削除が必要になり得る。
図４０は、例による、産業制御システムのための新しいアルゴリズムの自動作成を管理する方法のフローチャートを示す。フローチャート４０００は、新しい閉ループ作業負荷アルゴリズムの自動作成を管理するオペレーション４０１０を含む。フローチャート４０００は、プロセスに対する新しいアルゴリズムの品質および感度の評価を実行するオペレーション４０２０を含む。フローチャート４０００は、動作制約境界を自動的に確立するオペレーション４０３０を含む。フローチャート４０００は、既存のプロセスに対する新しいアルゴリズムの安全性を自動的に評価するオペレーション４０４０を含む。フローチャート４０００は、より広範なプロセスの価値を自動的に評価するオペレーション４０５０を含む。フローチャート４０００は、制御環境における配置の実現可能性についてシステムを自動的に評価するオペレーション４０６０を含む。フローチャート４０００は、新しいアプリケーション制御戦略を物理的に配置および監視するオペレーション４０７０を含む。フローチャート４０００は、新しいアルゴリズムをライフサイクル管理システムに統合するオペレーション４０８０を含む。フローチャート４０００は、新しいアルゴリズムをサポート終了処理に統合するオペレーション４０９０を含む。
［分散型制御環境での拡張可能なエッジ計算］
［分散型制御環境での拡張可能なエッジ計算］
現在のソリューションでは、エンドユーザが必要な計算量を推定し、将来の配置を証明するために追加の計算機能を追加する必要がある。これらの手法は、お金、電気、および熱エネルギーを浪費する。これはまた、計算が実際に必要になる前に、過剰に提供された計算が古い技術になる危険性もある。
本明細書で説明する技術により、産業システムの制御戦略のＣＰＵ性能のニーズを理解する集中型オーケストレーションシステムによって、産業制御システムのエッジ制御ノードで、初期の休止状態または停止状態から高性能ＣＰＵを起動できる。各エッジ制御ノードは、最初は低コスト、低性能のデバイスとして販売されているため、顧客の初期投資はわずかである。必要な計算（適切なサイズの計算）のみを購入して提供することで、金銭的投資、熱フットプリント、および電気エネルギー消費を最適化する。このソリューションは、制御システムに拡張可能な計算フットプリントを提供する。
図４１は、産業制御システム（ＩＣＳ）リングトポロジネットワーク４１０２を示す。
産業制御システムは一般に、プログラマブルロジックコントローラ４１０４、遠隔ＩＯ（ＲＩＯ）（例えば、４１０６）およびフィールドデバイス（例えば、４１０８）で構成されている。典型的な配置は、ＰＬＣ ４１０４によって制御される遠隔ＩＯユニットのリングで構成され得る。ＩＯおよびフィールド計算は、典型的には、ＰＬＣ４１０４にロックされ得る（例えば、図４１）。
図４２は、エッジ制御トポロジネットワークを示す。エッジ制御トポロジネットワークは、オーケストレーションサーバ４２０２（例えば、オーケストレーション９２０について上述したように）、ブリッジ４２０４、複数のエッジ制御ノード（例えば、ＥＣＮ４２０６）、および１つまたは複数のフィールドデバイス（例えば、４２０８）を含む。オーケストレーションサーバ４２０２は、例えばリングネットワークで相互に接続され、ブリッジ４２０４を介してオーケストレーションサーバ４２０２に接続されるＥＣＮデバイス（例えば、４２０６）で動作を提供、制御、またはオーケストレートするために使用される。
ＳＤＩＳがシステムの機能を向上させる１つの方法は、ＩＣＳ全体にわたる制御機能の分散である。オーケストレーションサーバ４２０２は、エッジ制御ノード４２０６を制御するために使用され得る。これは、単一デバイスでＩＯと計算の両方を実行するオプションを含み、オーケストレーションサービスを使用して作業負荷を最適な使用可能なリソースに分散する。
通常、エッジ制御ノード（ＥＣＮ）のリングは、熱的に制約された環境、例えば、気流がゼロまたは温度がオーケストレートされていないキャビネットに配置できる。例では、単一キャビネットに最大９６のＩＯがあり得、これは最大９６のＥＣＮを意味する。これにより、各ＥＣＮがＩＯと高性能計算の両方を含めることが禁止され得る。これは、高性能計算デバイスが過度の熱を生成し、周囲温度をＥＣＮの安全な動作レベルを超えて上昇させるためである。さらに、制御システムの高い計算需要がない場合は、すべてのＥＣＮで高性能プロセッサが必要になり得ない。したがって、本明細書で説明するシステムおよび技術は、制御戦略を実行するために必要な計算リソースだけをインストールし、コストおよび電力の目標を超えないようにしながら、各ＥＣＮの変更をまだ可能にする機能を提供する。したがって、例では、すべてのＥＣＮが高性能プロセッサまたは高い制御機能を備えているわけではない。
図４３は、エッジ制御ノード（ＥＣＮ）ブロック図である４３０２を示す。例では、以下の技術は、図４３に示されるような計算拡張可能ＥＣＮの導入により、計算問題の「適切なサイズ」の提供を提供する。
ＥＣＮ４３０２の主成分は、より高性能の計算（例えば、ＣＰＵ）４３０６および低性能の計算のためのマイクロプロセッサ（ＭＣＵ）４３０８の両方を有するシステムオンチップ４３０４であり得る。ＭＣＵ４３０８は、ＩＯサブシステム４３１２から来るＩＯデータを、ＯＰＣＵＡ Ｐｕｂ／ＳｕｂまたはＤＤＳなどのイーサネットＴＳＮに基づくミドルウェアなどのネットワークコンポーネント４３１０に変換するために使用され得る。ＥＣＮ４３０２は、高性能ＣＰＵ４３０６が停止状態にある顧客に配信され得る。例えば、特別な「起動信号」が、例えばオーケストレータから高性能ＣＰＵ ４３０６に送信されるまでなど、高性能ＣＰＵ ４３０６を停止状態で使用するためにアクセスできない場合がある（例えば、オーケストレータは、ＣＰＵ ４３０６を起動するためにＭＣＵ ４３０８に送信された信号を送信することができる）。
ＥＣＮ ４３０２は、ＭＣＵ ４３０８を使用したＩＯ変換用の低コスト、低電力デバイスとして最初にインストールできる。例えば、高性能ＣＰＵ ４３０６は最初は無効になっており、最初はＥＣＮ ４３０２は、ＳｏＣ ４３０４と起動されたＩＯサブシステム４３１２を含むが、高制御機能はない。高性能プロセッサ４３０６は停止であり得、例えば、ＥＣＮ４３０２は最初にＩＯ変換のみを可能にする。
図４４は、ＥＣＮに基づくリングトポロジ図を示す。図４４は、拡張可能計算ＥＣＮが従来のリングトポロジにどのように適合し得るかを示す。図４４はさらに、すべての高性能ＣＰＵが無効になっている配置の初期状態を示す。図４４に示すように、各ＥＣＮには、ＩＯをデータバス標準に変換する機能があるが、制御機能を実行する実際の機能はない。
例では、配置後、オーケストレーションサーバ４２０２は、必要な高性能ＣＰＵの数を決定し、次いで、特定のＥＣＮでそれぞれのＭＣＵを使用して１つまたは複数のＣＰＵを起動するコードを送信し得る。オーケストレーションサーバ４２０２は、オーケストレーションサーバ４２０２によって実行されるスケジューリング機能の一部としてコスト／利益分析を提供し得る。例では、毎月、毎年のライセンスなどのスケジュールに従ってなど、ＣＰＵ ４３０６を起動するために料金が課金され得る。ＣＰＵ４３０６は、必要に応じて（例えば、オーケストレータまたはユーザによって決定されるように）起動または停止され得る。制限付きライセンスは、完全な配置よりも安価であり得る。別の例では、いったん起動されると、ＣＰＵ ４３０６は無期限に起動されたままであり得る（例えば、一度限りの料金で永続的に起動される）。
例では、ＣＰＵ４３０６を起動しないことは、熱出力を低減し得る。これは、料金表とは別に管理できる。例えば、いったん起動されると、ＣＰＵ ４３０６は、（ＣＰＵ ４３０６が永久的に起動された例においてさえ）熱出力を節約するために停止されるか、または低電力状態に移行され得る。ＣＰＵ４３０６は、高電力状態で制御命令を実行し、実行が完了した場合、低電力状態に移行し得る。
例では、起動コードは、ＭＣＵ４３０８に送信される特別なパケットであり得る。起動コードは、コードがどれだけ有効であるかを決定することなどを含めて、ＭＣＵ４３０８によって有効性について評価され得る。ＭＣＵ４３０８は、（例えば、オーケストレータから信号を受信した後）ＣＰＵに直接起動信号を送信し得る。
ＭＣＵ ４３０８は、停止状態からＣＰＵ ４３０６を起動する場合に、電源レールをオンにし、ＣＰＵ ４３０６をブートし、最新のファームウェアをダウンロードするなどし得る。例では、ＣＰＵ４３０６は、ＣＰＵ４３０６をオフまたはオンにする代わりに起動または停止され得る低電力モードまたは高電力モードを有し得る。この例は、ＣＰＵ ４３０６をすばやく起動する必要がある場合など、ＣＰＵ ４３０６の電源をオフにする代わりに低電力状態にして熱出力を下げる場合に役立ち得る。
例では、低電力状態は、オーケストレータ４２０２がＣＰＵ製造業者から取得する暗号トークンを提供することによって実装され得る。これらのトークンは、ＭＣＵ ４３０８を介してＣＰＵ ４３０６に送信され得る。トークンは、例えば、ＣＰＵ製造業者およびＣＰＵ４３０６のみが知っている（例えば、製造時にＣＰＵ４３０６に焼き付けられる）キーを使用して署名され得、各トークンが確認されることを可能にする。各トークンは一意であり得、ＣＰＵ ４３０６が一定時間実行することを可能にする。
別の例では、トークンは、製造者およびＭＣＵ ４３０８に知られている秘密を使用してＭＣＵ ４３０８によって認証される。例えば、ＭＣＵ ４３０８およびＣＰＵ ４３０６がＳｏＣの単一パッケージで一緒に製造されている限り。この例では、トークンを確認するためにＣＰＵ ４３０６をウェイクアップさせることによって作成されるサービス拒否攻撃を防ぐことができる。
図４５は、ＥＣＮに基づくリングトポロジを通るデータフローを示す。例では、オーケストレーションシステム４２０２は、制御戦略を分析して、制御戦略の計算ニーズを満たすためにどれだけの計算が必要かを理解する。オーケストレーションシステムが計算要件を生成すると、エンドユーザは必要な量の高性能ＣＰＵ起動コードをＥＣＮベンダーから購入できる。オーケストレーションシステム４２０２は、認証された起動コードをＥＣＮのアレイ内の指定されたＥＣＮに送信する。これにより、計算リソースが有効になる。このフローを図４５に示す。
計算を可能にするプロセスは、１回限りのイベントである必要はない。制御戦略の複雑さが増し、計算の需要が高まるにつれ、エンドユーザは引き続きより多くの計算リソースを購入して起動する（または不要な場合はＣＰＵリソースを停止する）ことができる。例えば、オーケストレータは、停止信号をＥＣＮに送信して、そのＥＣＮでＣＰＵを停止し得る。ＥＣＮベンダーは、エンドユーザが月次または年次で起動ライセンスを購入する一時的なサービスモデルを実装し得る。このモデルでは、エンドユーザが起動コードを期限切れにすることもできるため、一部の計算リソースを低電力の休止状態に戻して、定期的な料金を節約できる。
図４６Ａは、例による、（例えば、ＥＣＮの）ＣＰＵを起動する方法のフローチャート４６００Ａを示す。フローチャート４６００Ａは、オーケストレーションサーバにおいて、産業制御システム（例えば、リング配置）におけるエッジ制御ノードの計算要件を決定するオペレーション４６１０Ａを含む。フローチャート４６００Ａは、１つまたは複数のエッジ制御ノードのＣＰＵを起動する指示を受信するか、または１つまたは複数のＣＰＵを起動する必要があることを決定するオペレーション４６２０Ａを含む。フローチャート４６００Ａは、起動されるＣＰＵを有するエッジ制御ノードに認証された起動コードを送信するオペレーション４６３０Ａを含む。例では、オペレーション４６１０Ａ〜４６３０Ａ（上記）は、オーケストレーションサーバによって実行され得、オペレーション４６４０Ａ〜４６７０Ａ（下記）は、ＥＣＮによって実行され得る。フローチャート４６００Ａを使用する方法は、オペレーション４６１０Ａ〜４６３０Ａまたは４６４０Ａ〜４６７０Ａあるいは両方を実行する段階を含み得る。
フローチャート４６００Ａは、エッジ制御ノードで認証された起動コードを受信するオペレーション４６４０Ａを含む。フローチャート４６００Ａは、エッジ制御ノード（例えば、ＣＰＵ）でコードを認証するオペレーション４６５０Ａを含む。フローチャート４６００Ａは、ＭＣＵ（低性能プロセッサ）を使用してエッジ制御ノードのＣＰＵを起動するオペレーション４６６０Ａを含む。フローチャート４６００Ａは、エッジ制御ノードでオーケストレーションサーバから更新を受信してＣＰＵを停止するか、ＣＰＵを低電力状態にするオプションのオペレーション４６７０Ａを含む。例では、ＥＣＮは、産業制御システムのリングネットワークの一部であり得る。
図４６Ｂは、例による、ＣＰＵを起動する方法のフローチャート４６００Ｂを示す。フローチャート４６００Ｂのオペレーションは、オーケストレーションサーバによって実行され得る。オーケストレーションサーバは、ブリッジデバイスなどを介して、エッジ制御ノードのリングネットワークに通信可能に結合し得る。
フローチャート４６００Ｂは、産業制御システムにおけるエッジ制御ノードの計算要件を決定するためのオプションのオペレーション４６１０Ｂを含む。例では、エッジ制御ノードは、ブリッジデバイスがネットワークをオーケストレーションサーバに接続するリングトポロジネットワーク内のノードであり得る。
フローチャート４６００Ｂは、オーケストレーションサーバをエッジ制御ノードに接続するブリッジを介してＩＯデータを受信するオペレーション４６２０Ｂを含む。ＩＯデータは、ＩＯサブシステムで生成されたデータからエッジ制御ノードのマイクロコントローラ（ＭＣＵ）で変換され得る。変換は、エッジ制御ノード（ＭＣＵも含み得る）のシステムオンチップのイーサネットスイッチによって送信されるパケットへの変換であり得る。別の例では、ＭＣＵによって変換されたデータは、フィールドデバイスまたはエッジ制御ノードの電力状態など、ＭＣＵ自体によって生成されたデータであり得る。
フローチャート４６００Ｂは、認証された起動コードをエッジ制御ノードに送信して、エッジ制御ノードのＣＰＵを起動するオペレーション４６３０Ｂを含み、このＣＰＵは最初は停止状態にある。例では、認証された起動コードは、ＣＰＵが起動する前にＭＣＵによって認証される。
フローチャート４６００Ｂは、実行のために処理命令をＣＰＵに送信するオペレーション４６４０Ｂを含む。
フローチャート４６００Ｂは、エッジ制御ノードのＣＰＵを停止するために停止コードをエッジ制御ノードに送信するオプションのオペレーション４６５０Ｂを含む。
この方法は、エッジ制御ノードを含む産業制御システムにおけるエッジ制御ノードの計算要件を決定するオペレーションを含み得る。例では、産業制御システムの制御戦略を満たすためにＣＰＵが起動する必要があるというオーケストレーションサーバによる決定に基づいて、ＣＰＵは起動する。別の例では、オーケストレーションサーバは、複数のエッジ制御ノードのうちのこのエッジ制御ノードのＣＰＵを起動する指示を受信することができる。
［アプリおよびクライアントサーバフレームワークの分散型動的アーキテクチャ］
［アプリおよびクライアントサーバフレームワークの分散型動的アーキテクチャ］
オーケストレーションシステムでは、例では、アプリケーションはトポロジを介して相互接続された一連のモジュールとして定義される。これらのモジュールは、異なるロジックノードに配置される。各ロジックノードは物理ノードに対応し得るが、マッピングは１：１である必要はない。リソース要件が満たされている限り、複数のロジックノードは１つの物理ノードにマッピングされるか、複数のモジュールは同じ物理環境に配置され得る。
異なるモジュールが配置されると、モジュールまたはノードの様々なエラー、クラッシュ、またはリブートが発生し得る。配置されたアプリケーションの回復力を向上させるために、冗長性を使用して可用性を向上させることができる。例えば、モジュールは２つのノードに配置できる（例えば、プライマリおよびバックアップとして）。プライマリノードでエラーが発生した場合、またはその他の方法で故障した場合、オーケストレータはバックアップノードに切り替えて、それを引き継ぐことができる。ただし、停止したモジュールの状態を保存することは、多くの場合重要である。本明細書に開示されるシステムおよび技術では、システムは、自動バックアップノードとして機能するか、またはバックアップを生成するように連携し得るアプリケーショントポロジ内の同じレベルのノード間のピアツーピア関係を含む。ピアツーピア連携を使用すると、保存された状態を使用できるようになる。これは、通信チャネルをリッスンする段階と、モジュールまたはノードが故障あるいはクラッシュした場合に別のノードにモジュールを再配置する段階とを含む。
現在の冗長ソリューションは手動で定義されるか、冗長な方法で作成される。これにより、信頼性は高くなるが、リソースの重複が必要になるため、コストも高くなる。多くの場合、手動による冗長性を定義して維持することは困難である。多くの場合、ポリシーは単純すぎて、必要なリソースが多すぎる。さらに、中央オーケストレータに冗長ノードを識別したり、故障したノードを交換したり要求することは、コストがかかり、時間がかかる。
例では、本明細書で説明する技術は、アプリケーションの通信パターンに基づくモジュールの自動冗長ノードを作成し得る。例えば、第１モジュールが第２モジュールにデータを送信する場合、第２モジュールをホストしているノードが第１モジュールの自動冗長になり得る。第１モジュールによって生成されたデータは第２モジュールに供給され、第１モジュールが第２モジュールへの入力を認識できるようにする。第１モジュールが第２モジュールだけでなく複数のモジュールにデータを送信する場合、他の問題が発生し得る（または、第２モジュールが第１モジュール以外のモジュールから入力を受信した場合）。これらのシナリオでは、これらのリーフノードのいずれかに冗長性を作成することが困難であり得る。代わりに、同じ層上のノードのコレクションによって作成されたピアツーピアネットワークが、冗長ノードのステータスをネゴシエートし得る。このノードのネットワークは、他のアプリケーションに大きな影響を与えることなく、冗長なセットを相互に交換できる。
図４７は、アプリケーション接続図の例を示す。例では、アプリケーションを形成する異なるモジュールは、図４７に示される例のような配置で構成され得る。接続は、異なるモジュール間のデータのフローを示す。これらのモジュールは、クライアント／サーバモードまたはパブ／サブモードで実行できる通信チャネルを使用してデータを送信する。この例では、オーケストレータがこれらのモジュールを配置する場合に、オーケストレータが各モジュールを個別の計算ノードに配置するか、単一ノードに複数のモジュールを配置するかを選択できる。この例では、簡単にするために、単一モジュールが単一ノードに配置されている。他の例では、故障したノードに複数のモジュールがある場合、またはモジュールにエラーがある場合（例えば、ノードの別のモジュールにエラーがない場合）に、冗長オプションを提供し得る。
例では、ノード４７２０のモジュールＢは、ノード４７４０のモジュールＥとノード４７３０のＤの両方にデータを送信している。モジュールＢで故障する場合、次のオペレーションが実行され得る。オペレーションは、ノード４７１０、ノード４７３０、およびノード４７４０などのピアツーピアノードによって実行され得る。実行は、故障を検出する段階と、交換ノードへのモジュールＢを再配置する段階（例えば、ノード４７２０が故障した場合）とを含み得、必要に応じて入力（例えば、モジュールＡから）または出力（例えば、モジュールＥまたはＤへ）を再配線し、モジュールＢの以前の状態を回復でき、交換ノードに転送され得る。
図４７に示す例では、モジュールＢの隣接（例えば、モジュールＡ、Ｄ、およびＥ）は、モジュールＢが故障した場合（例えば、ノード４７２０が故障した場合）を引き継ぐ目的でピアツーピアネットワークを作成し得る。この例では、モジュールＡ、Ｄ、およびＥがモジュールＢの入出力チャネルと直接接触しているため、隣接モジュールはモジュールＢの状態を再現するように配置されている。これらの３つの隣接モジュールは、リーダー選出アルゴリズムまたは交換ノードを選択するための他の技術を通過し得る。
例では、モジュールＢの実行可能ファイルは、３つのノード（例えば、４７１０、４７３０、または４７４０）のうちの１つまたは複数に配置され得るか、または３つのノードのうちの１つまたは複数は、冗長ソフトウェアが存在する場所を管理し得る。例では、これらの３つのノードのうちの１つまたは複数は、ノード４７２０が故障した場合に、入力または出力のルーティングを管理し得る。別の例では、故障が検出されない場合でも（例えば、冗長性の目的で）、データをルーティングし得る。これらの技術の１つを使用してモジュールＢをバックアップすると、故障した場合に冗長ノードへのシームレスな切り替えが可能になる。これは、これらのノードがデータのフローを制御しているためである。例では、冗長ノードまたはノード群は、冗長性としてオペレーション期間全体にわたってソフトウェアを備えたシャドウノードを実行し得る。
図４７に示す例では、モジュールＢにはモジュールＡ、Ｄ、およびＥの隣接がある。これら４つのモジュールは、Ｂ（例えば、ピアツーピアネットワーク）の周辺の近接を確立し、モジュールＢが故障した場合の緊急時対応計画を作成する。計画は、リーダー選出アルゴリズムまたは他の技術を使用して制御ノードを選択することを含み得る（例えば、ノード４７１０は、ノード４７１０の追加のリソース上など、モジュールＢの冗長ノードを実行するためのより多くのリソースを有するとして選出される）。制御ノードまたは選択された交換ノードは、故障したノード４７２０に直接接続され得ず、モジュールＢの冗長性を保存し得る。ノード４７２０が故障する場合、モジュールＢに冗長性があり、次いで、冗長ノードはモジュールＢをシームレスに実行し得る。例えば、モジュールＡは、モジュールＢの冗長バージョンを実行している冗長ノードについてモジュールＢに知らせるためのチャネルを作成できる。次に、モジュールＢと冗長バージョンが接触し得、モジュールＢは、状態の詳細を冗長モジュールに送信して、モジュールＢがクラッシュした場合に備えて、冗長モジュールがコンテキストを認識できるようにする。
図４８は、冗長ノードを備えたアプリケーションのアーキテクチャのビューの例を示す。図４８において、モジュールＡ、Ｄ、およびＥをホストする３つのノード（４８１０、４８３０、および４８４０）は、ピアツーピアネットワークを形成する。モジュールＡはネットワークのリーダーであり、冗長ノード４８２５上のホスティングモジュールＢ'を管理する。モジュールＡは、その出力を入力としてノード４８２０および４８２５の両方にルーティングすることもできる。図４８の例では、モジュールＢ'が何にも接続されていなくても、モジュールＢ'は常に出力（例えば、モジュールＢと同じ）を計算している。
この配置により、アプリケーションはオーケストレータ４８０５とは無関係に独自の回復力の所有権を取得する（アプリケーションまたはネットワーク構成のセットアップに使用され得、その後切断され得る）。アプリケーションの独立性により、信頼性を犠牲にすることなくオーケストレータ４８０５からの完全な切断が可能になり得る。
特定の例では、モジュールをホストしている物理ノードがリソース制限されている場合、モジュールＢ'ですべての計算を実行することが実行可能ではない場合がある。ただし、完全な冗長性を実現するために、以下で説明するオプションの１つを実装できる。
１つのオプションは、仮想マシンでモジュールＢを実行する段階を含む。この例では、システムは、使用可能なリソースがそれを行うことができる場合は常時、残りのアプリケーションのオペレーションを損なうことなく（例えば、ノードの停止時間または追加のリソースが使用可能になるのを待つことにより）、仮想マシンのコピーを作成できる。そうすることで、モジュールＢの状態を確保できる（例えば、仮想マシンのイメージとして）。
別のオプションでは、モジュールＢが交換をサポートし得る。これにより、モジュールＢは、内部パラメータと状態情報をモジュールＢ'に提示するインタフェースを有し得る。この冗長オペレーションは定期的に実行され得、モジュールＢがその状態を保存できるようにする。更新の頻度は、モジュールＢの大きさと、様々なモジュールおよびアプリケーション全体の要件を引き続き満たしながら更新を実行できるかどうかに依存し得る。
例では、モジュールＤがリーダーとして選出される場合、モジュールＤは、データが失われないようにするためにモジュールＢ'が必要とするすべてのチャネルをリッスンする（例えば、モジュールＡからの出力）。これにより、必要な場合にデータをモジュールＢ'に転送できる。同様に、モジュールＤは、モジュールＤがチャネルを直接リッスンすることなく、チャネル（例えば、モジュールＡからの出力）をリッスンするようにモジュールＢ'を設定できる。
一部の例では、オーケストレータまたはアプリケーション開発者は、特定のモジュールがアプリケーションにとって非常に重要であるか、単一故障点であると決定し得る。このシナリオでは、このモジュールに２つ以上の冗長モジュールを割り当てることができる。例えば、３つのノードにより形成されるネットワークは、次いで、複数の冗長モジュール（例えば、モジュールＢ'およびモジュールＢ''、図示せず）を作成できる。これらのモジュールのそれぞれは、多様性を作成したり、回復力を追加したりするための異なる同期ポリシーを有し得る。
通常、アプリケーションはサイロに存在しないが、他のアプリケーションに接続されることがよくある。上記の技術およびシステムと同様に、モジュールをアプリケーションに置き換えることで、システムはマイクロレベルまたはマクロレベルで冗長性を提供できる。例えば、アプリケーションＩはアプリケーションＩＩに接続し、冗長性と冗長性のポリシーを作成するリーダーになり得る（例えば、アプリケーションが故障した場合）。
連鎖的な故障または大きな混乱が発生した場合、このような戦略を作成し、アプリケーションが独自のポリシーの所有権を取得できるようにすると、不要なコストをかけずに冗長性を提供できる。多くの場合、完全に分散したシステムは管理が難しくなるが、単一故障点になり得る中央の権限がないため、高度な復元力を提供する。したがって、この場合、各アプリケーションは、独自の信頼性ポリシーと戦略を有し得る。例では、アプリケーションは相互に接続し、独自のマクロ信頼性戦略を適用できる。例では、２つまたはそれより多くのモジュール、ノード、またはアプリケーションが故障する場合、残りのモジュール、ノード、またはアプリケーションが故障の冗長性として機能し得る。例えば、２つのノードが故障した場合、１つのノードが両方を置き換えるか、２つまたはそれより多くのノードが２つの故障したノードを置き換えることができる。
マクロまたはマイクロの信頼性戦略を備えた冗長アプリケーションまたはモジュールは、システムがセキュリティ攻撃を受けている場合に保護を提供し得る。マクロレベルで複数の故障が検出され得、それに応じて戦略が変更され得る。例えば、故障が近くにあるアプリケーションを一掃する可能性がある場合、配置の戦略は、意図的に、遠く離れた隣人をコミュニティの一部として割り当て、状態、モジュール、またはアプリケーションを完全な故障から保護し得る。図４８の例でセキュリティを考えると、モジュールＦまたはモジュールＣは、ネットワークに参加し、役割を割り当てられ得る。役割はリーダーではなく、コミュニティのメンバーであり得る。つまり、モジュールＣは、モジュールＢ'の管理に多くのリソースを費やし得ない。代わりに、モジュールＣはモジュールＢの冗長コピーを作成し得るが（例えば、頻繁に）、インスタンス化しない。これにより、シームレスな特性の一部が犠牲になり得る（例えば、状態が少し古くなり得る）が、システム全体に最小限のコストで追加の保証と冗長性の層を提供する。業務用のデータセンターの一部が使用できなくなった場合に、別の場所にある別のデータセンターがわずかに古い状態と内部変数の値を引き継いでオペレーションを続行できるように、同じ概念がアプリケーションに適用され得る。
図４９Ａは、例による、アプリケーションの通信パターンに基づいて、冗長ノード上にアプリケーションの自動冗長モジュールを作成する方法のフローチャートを示す。フローチャート４９００Ａは、ピアツーピア隣接ネットワークを作成するオペレーション４９１０Ａを含む。フローチャート４９００Ａは、冗長ノード上に冗長モジュールをレンダリングするオペレーション４９２０Ａを含み、冗長モジュールは、ノード上のアプリケーションのモジュールに対応する。フローチャート４９００Ａは、モジュールのノードの故障を検出するオペレーション４９３０Ａを含む。フローチャート４９００Ａは、入力と出力をモジュールから冗長モジュールに再配線することにより、冗長ノード上の冗長モジュールを起動するオペレーション４９４０Ａを含む。フローチャート４９００Ａは、モジュールから以前の状態を回復して冗長モジュールに転送するオペレーション４９５０Ａを含む。フローチャート４９００Ａは、冗長モジュールを使用してモジュールの実行を継続するオペレーション４９６０Ａを含む。フローチャート４９００Ａは、ノードの故障を報告するオペレーション４９７０Ａを含む。
図４９Ｂは、例による、ＣＰＵを起動する方法のフローチャート４９００Ｂを示す。フローチャート４９００Ｂのオペレーションは、オーケストレーションサーバによって実行され得る。
フローチャート４９００Ｂは、オーケストレーションシステム上で実行するための一連の分散型ノードを含むアプリケーションを構成するためのオプションのオペレーション４９１０Ｂを含む。フローチャート４９００Ｂは、第１ノード上で第１モジュールを実行するオペレーション４９２０Ｂを含み、第１モジュールは第１出力を有する。フローチャート４９００Ｂは、第２ノードで第２モジュールを実行するオペレーション４９３０Ｂを含み、第２モジュールは、第１出力を入力として使用する。フローチャート４９００Ｂは、第２モジュールから第３ノードで実行されている第３モジュールに第２出力を提供するオペレーション４９４０Ｂを含む。
フローチャート４９００Ｂは、第２ノードの故障の検出に応答して実行され、第１ノードと第３ノードとの間で連携することによって第２モジュールを再配置するための交換ノードを決定するオペレーション４９５０Ｂを含む。例では、交換ノードを決定する段階は、第１出力を受信し、第２モジュールを動作させるように事前構成された冗長ノードを識別する段階を含む。冗長ノードは、冗長ノードが交換ノードとして動作する後まで、任意のノードから切断され（例えば、任意のノードに出力を提供できない）得、例えば、第２モジュールの状態を維持するために入力を受信し、出力を計算するが、他のノードには接続されない。例では、第２モジュールに関するパラメータおよび状態情報は、定期的に、出力が常に生成される場合などは常に、第２ノード、第１ノード、または第３ノードから冗長ノードに送信され得る。別の例では、冗長ノードの故障に応答して、第２冗長ノードが識別されて（例えば、重要なモジュールの）交換ノードになることができる。
例では、冗長ノードを決定する段階は、第２ノードに接続された一連のノードを決定する段階を含む。一連のノードは、方向指示などを伴う、１つまたは複数の入力ノードまたは１つまたは複数の出力ノードを含み得る。交換ノードは、例えば、第１ノードに接続されて第１モジュールから出力を受信し、第３ノードに接続されて第２モジュールから第３モジュールに出力を提供し得る。
さらなるオペレーションは、第１出力が生成される場合、第１ノードなどで、第２モジュールの冗長状態を得る保存する段階を含み得る。例では、オーケストレーションサーバは、最初にノード上のモジュールの構成（例えば、第１ノード上の第１モジュールなど）を生成し得る。この例では、オーケストレーションサーバは、例えば、第２ノードの故障などの任意の故障の前に切断され得る。第１ノードおよび第３ノードは、オーケストレーションサーバの助けを借りずに、連携して交換ノードを決定できる。例では、第２ノードは、仮想マシンに埋め込まれ得る。次に、仮想マシン上の第２ノードのイメージに基づいて、第２モジュールを交換ノードでインスタンス化できる。
［ＩｏＴデバイスおよびネットワーク］
［ＩｏＴデバイスおよびネットワーク］
上述の技術は、任意の数のＩｏＴネットワークおよびトポロジの技術におけるものを含む、様々なデバイスの配置に関連して実装され得る。したがって、本技術の様々な実施形態は、異種および同種ネットワーク間のエッジデバイス、フォグおよび中間デバイス、ならびにクラウドエンティティの連携を含み得ることが理解されよう。このようなネットワークのトポロジと配置の例の一部を、次の段落で提供する。
図５０は、リンクを介してそれぞれのゲートウェイに結合されたそれぞれのモノのインターネット（ＩｏＴ）ネットワークの例示的なドメイントポロジを示す。モノのインターネット（ＩｏＴ）は、多数のコンピューティングデバイスが相互に、およびインターネットに相互接続され、非常に低いレベルで機能およびデータ収集を提供するという概念である。したがって、本明細書で使用されるように、ＩｏＴデバイスは、特に、他のＩｏＴデバイスおよびインターネットなどのより広いネットワークと通信する、感知または制御などの機能を実行する半自動デバイスを含み得る。
ＩｏＴデバイスは、ネットワーク上で通信できる物理オブジェクトであり、センサ、アクチュエータ、およびその他の入力／出力コンポーネント（データを収集したり、実際の環境から動作を実行するなど）を含み得る。例えば、ＩｏＴデバイスは、建物、車両、パッケージなどの日常的なものに埋め込まれた、または取り付けられた低電力デバイスを含み、それらの物に付加的なレベルの人工知覚認識を提供し得る。近年、ＩｏＴデバイスの普及により、これらのデバイスを利用したアプリケーションが急増している。
多くの場合、ＩｏＴデバイスはメモリ、サイズ、または機能が制限されているため、少数の大型デバイスと類似のコストで多数のデバイスを配置できる。ただし、ＩｏＴデバイスは、スマートフォン、ラップトップ、タブレット、ＰＣ、またはその他のより大きなデバイスであってよい。さらに、ＩｏＴデバイスは、スマートフォンまたは他のコンピューティングデバイス上のアプリケーションなどの仮想デバイスであってよい。ＩｏＴデバイスは、データストレージ、プロセス制御などのためにＩｏＴデバイスを他のＩｏＴデバイスおよびクラウドアプリケーションに結合するために使用されるＩｏＴゲートウェイを含み得る。
ＩｏＴデバイスのネットワークは、配水システム、配電システム、パイプライン制御システム、プラント制御システム、光スイッチ、サーモスタット、ロック、カメラ、アラーム、モーションセンサなどの商用および家庭用自動化デバイスを含み得る。ＩｏＴデバイスは、遠隔コンピュータ、サーバ、および他のシステムを介してアクセスでき、例えば、システムを制御したり、データにアクセスしたりできる。
インターネットおよび同様のネットワークの将来の成長は、非常に多数のＩｏＴデバイスを含み得る。したがって、本明細書で説明する技術のコンテキストでは、このような将来のネットワーキングのための多くのイノベーションにより、これらすべての層が妨げられずに成長し、アクセス可能な接続リソースを発見および作成し、接続リソースを非表示および区分化する機能をサポートするニーズに対処する。任意の数のネットワークプロトコルおよび通信標準を使用できる。各プロトコルおよび標準は、特定の目的に対処するように設計されている。さらに、プロトコルは、場所、時間または空間に関係なく動作する人間がアクセス可能なサービスをサポートするファブリックの一部である。イノベーションは、サービスの提供と、ハードウェアやソフトウェアなどの関連インフラストラクチャ、セキュリティの強化、サービスレベルおよびサービス提供契約で指定されたサービス品質（ＱｏＳ）条件に基づくサービスの提供を含む。理解されるように、上記のシステム例で紹介されたようなＩｏＴデバイスおよびネットワークの使用は、有線および無線技術の組み合わせを含む接続の異種ネットワークにおける多くの新しい課題を提示する。
図５０は、具体的には、バックボーンリンク５００２を介してそれぞれのゲートウェイ５０５４に結合されたＩｏＴネットワーク５０５６、５０５８、５０６０、５０６２を備えたＩｏＴデバイス５００４を含む多くのモノのインターネット（ＩｏＴ）ネットワークに使用され得るドメイントポロジの簡略図を提供する。例えば、いくつかのＩｏＴデバイス５００４は、ゲートウェイ５０５４と、およびゲートウェイ５０５４を介して相互に通信し得る。図面を簡略化するために、すべてのＩｏＴデバイス５００４、または通信リンク（例えば、リンク５０１６、５０２２、５０２８、または５０３２）にラベルが付けられているわけではない。バックボーンリンク５００２は、光ネットワークを含む任意の数の有線または無線技術を含み得、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、またはインターネットの一部であり得る。さらに、このような通信リンクは、様々なデバイスの相互接続を容易にするＭＵＸｉｎｇ／ｄｅＭＵＸｉｎｇコンポーネントの使用を含む、ＩｏＴデバイス５００４とゲートウェイ５０５４との間の光信号パスを容易にする。
ネットワークトポロジは、ブルートゥース低エネルギー（ＢＬＥ）リンク５０２２を使用するネットワーク５０５６を備えたメッシュネットワークなど、任意の数のタイプのＩｏＴネットワークを含み得る。存在し得る他のタイプのＩｏＴネットワークは、ＩＥＥＥ８０２．１１（Ｗｉ−Ｆｉ（登録商標））リンク５０２８を介してＩｏＴデバイス５００４と通信するために使用される無線ローカルエリアネットワーク（ＷＬＡＮ）ネットワーク５０５８、ＬＴＥ／ＬＴＥ−Ａ（４Ｇ）または５Ｇセルラーネットワークを経由してＩｏＴデバイス５００４と通信するために使用されるセルラーネットワーク５０６０、および低電力ワイドエリア（ＬＰＷＡ）ネットワーク５０６２、例えば、ＬｏＲａアライアンスによって公布されたＬｏＲａＷａｎ仕様と互換性のある低電力ワイドエリアネットワーク（ＬＰＷＡ）、またはインターネットエンジニアリングタスクフォース（ＩＥＴＦ）によって公布された仕様と互換性のある低電力ワイドエリアネットワークを介したＩＰｖ６（ＬＰＷＡＮ）ネットワークを含む。さらに、それぞれのＩｏＴネットワークは、ＬＴＥセルラーリンク、ＬＰＷＡリンク、またはＺｉｇｂｅｅ（登録商標）などのＩＥＥＥ８０２．１５．４標準に基づくリンクなどの任意の数の通信リンクを使用して、外部ネットワークプロバイダ（例えば、レイヤ２またはレイヤ３プロバイダ）と通信し得る。それぞれのＩｏＴネットワークは、制約付きアプリケーションプロトコル（ＣｏＡＰ）などの様々なネットワークおよびインターネットアプリケーションプロトコルを使用して動作することもできる。それぞれのＩｏＴネットワークは、リンクされたデバイスとネットワークのクラスタツリーを形成するリンクのチェーンを提供するコーディネータデバイスと統合することもできる。
これらのＩｏＴネットワークの各々は、本明細書で説明されているような新しい技術機能の機会を提供し得る。改善された技術およびネットワークは、フォグデバイスまたはシステムとしてのＩｏＴネットワークの使用を含む、デバイスおよびネットワークの急激な成長を可能にし得る。このような改善された技術の使用が拡大するにつれて、ＩｏＴネットワークは、直接的な人間の介入を必要とせずに、自己管理、機能の進化、およびコラボレーションのために配置され得る。改善された技術により、集中制御されたシステムがなくてもＩｏＴネットワークが機能し得る。したがって、本明細書で説明する改善された技術を使用して、現在の実装をはるかに超えたネットワーク管理およびオペレーション機能を自動化および強化し得る。
例では、バックボーンリンク５００２などを介したＩｏＴデバイス５００４間の通信は、認証、承認、および会計（ＡＡＡ）のための分散型システムによって保護され得る。分散型ＡＡＡシステムでは、相互接続された異種ネットワークインフラストラクチャ全体にわたって、分散型支払い、クレジット、監査、承認、および認証システムを実装できる。これにより、システムおよびネットワークは自動オペレーションに移行できる。これらのタイプの自動オペレーションでは、マシンは人的資源を請け負ったり、他のマシンネットワークとのパートナーシップをネゴシエートしたりすることさえできる。これにより、相互の目標および概説された計画されたサービスレベル契約に対してバランスの取れたサービスを実現できるほか、計測、測定、トレーサビリティ、追跡可能性を提供するソリューションを実現できる。新しいサプライチェーンの構造および方法を作成することで、人間が関与することなく、多数のサービスを作成し、価値を求めて掘り出し、折りたたむことができる。
このようなＩｏＴネットワークは、音、光、電子トラフィック、顔およびパターンの認識、匂い、振動などの感知技術をＩｏＴデバイス間の自動組織に統合することでさらに強化できる。感覚システムの統合により、体系的かつ自動的な通信と、契約サービス目標に対するサービス提供の連携、オーケストレーションおよびサービス品質の（ＱｏＳ）に基づく群れとリソースの融合が可能になる。ネットワークに基づくリソース処理の個々の例の一部は、次のものを含む。
例えば、メッシュネットワーク５０５６は、インラインのデータから情報への変換を実行するシステムによって強化され得る。例えば、マルチリンクネットワークを含む処理リソースの自己形成チェーンは、生データから情報への変換を効率的に分散し、アセットとリソース、および各々の関連する管理を区別する機能を分散できる。さらに、インフラストラクチャおよびリソースに基づく信頼とサービスインデックスの適切なコンポーネントを挿入して、データの整合性、品質、保証を改善し、データの信頼性の指標を提供し得る。
例えば、ＷＬＡＮネットワーク５０５８は、標準変換を実行してマルチ標準接続を提供するシステムを使用し得、異なるプロトコルを使用して通信するＩｏＴデバイス５００４を可能にする。さらなるシステムは、目に見えるインターネットリソースと隠されたインターネットリソースを含むマルチ標準インフラストラクチャ全体でシームレスな相互接続を提供し得る。
例えば、セルラーネットワーク５０６０における通信は、データをオフロードする、通信をより多くの遠隔デバイスに拡張する、またはその両方を行うシステムによって強化され得る。ＬＰＷＡネットワーク５０６２は、非インターネットプロトコル（ＩＰ）からＩＰへの相互接続、アドレス指定、およびルーティングを実行するシステムを含み得る。さらに、ＩｏＴデバイス５００４の各々は、そのデバイスとのワイドエリア通信のための適切なトランシーバを含み得る。さらに、各ＩｏＴデバイス５００４は、追加のプロトコルおよび周波数を使用して通信するための他のトランシーバを含み得る。これは、図５２および５３に示されるＩｏＴ処理デバイスの通信環境およびハードウェアに関してさらに説明される。
最後に、ＩｏＴデバイスのクラスタは、他のＩｏＴデバイスやクラウドネットワークと通信するように装備できる。これは、ＩｏＴデバイスがデバイス間にアドホックネットワークを形成することを可能にし得、単一デバイスとして機能することを可能にし、これはフォグデバイスと呼ばれ得る。この構成は、図５１以下に関してさらに説明される。
図５１は、クラウドコンピューティングネットワークのエッジでフォグデバイスとして動作するＩｏＴデバイス（デバイス５１０２）のメッシュネットワークと通信するクラウドコンピューティングネットワークを示す。ＩｏＴデバイスのメッシュネットワークは、フォグ５１２０と呼ばれ得、クラウド５１００のエッジで動作し得る。図を簡略化するために、すべてのＩｏＴデバイス５１０２にラベルが付いているわけではない。
フォグ５１２０は、大規模に相互接続されたネットワークであると見なすことができ、多数のＩｏＴデバイス５１０２が、例えば、無線リンク５１２２によって相互に通信している。例として、この相互接続されたネットワークは、オープンコネクティビティファンデーション（登録商標）（ＯＣＦ）によってリリースされた相互接続仕様を使用して促進できる。この標準により、デバイスは相互に発見し、相互接続のための通信を確立できる。他の相互接続プロトコルも使用され得る。例えば、特に最適化されたリンクステートルーティング（ＯＬＳＲ）プロトコル、モバイルアドホックネットワーキング（Ｂ．Ａ．Ｔ．Ｍ．Ａ．Ｎ．）ルーティングプロトコルへの優れた手法、またはＯＭＡライトウェイトＭ２Ｍ（ＬＷＭ２Ｍ）プロトコルなどを含む。
この例では、３つのタイプのＩｏＴデバイス５１０２、例えば、ゲートウェイ５１０４、データアグリゲータ５１２６、およびセンサ５１２８が示されているが、ＩｏＴデバイス５１０２と機能の任意の組み合わせが使用され得る。ゲートウェイ５１０４は、クラウド５１００とフォグ５１２０との間の通信を提供するエッジデバイスであり得、また、モーションデータ、フローデータ、温度データなどのようなセンサ５１２８から取得されたデータのためのバックエンドプロセス機能を提供し得る。データアグリゲータ５１２６は、任意の数のセンサ５１２８からデータを収集し、分析のための処理機能を実行し得る。結果、生データ、またはその両方は、ゲートウェイ５１０４を介してクラウド５１００に沿って渡され得る。センサ５１２８は、例えば、データを収集することおよびデータを処理することの両方が可能な完全なＩｏＴデバイス５１０２であり得る。場合によっては、センサ５１２８は、例えば、データを収集し、データアグリゲータ５１２６またはゲートウェイ５１０４がデータを処理することを可能にするなど、機能においてより制限され得る。
任意のＩｏＴデバイス５１０２からの通信は、ＩｏＴデバイス５１０２のいずれかの間の便利な経路（例えば、最も便利な経路）に沿って渡されて、ゲートウェイ５１０４に到達し得る。これらのネットワークでは、多数の相互接続により実質的な冗長性が提供され、多数のＩｏＴデバイス５１０２が失われた場合でも通信を維持できる。さらに、メッシュネットワークの使用は、別のＩｏＴデバイス５１０２に接続するための範囲は、ゲートウェイ５１０４に接続するための範囲よりもはるかに小さい場合があるため、非常に低電力であるか、またはインフラストラクチャから離れた場所にあるＩｏＴデバイス５１０２が使用されることを可能にし得る。
これらのＩｏＴデバイス５１０２から提供されるフォグ５１２０は、クラウド５１００のエッジに位置する単一デバイス、例えばフォグデバイスとして、サーバ５１０６などのクラウド５１００内のデバイスに提示され得る。この例では、フォグデバイスからのアラートは、フォグ５１２０内の特定のＩｏＴデバイス５１０２からのアラートであると識別されずに送信され得る。このように、フォグ５１２０は、特にデータ分析、データ集約、および機械学習などの処理またはデータ集約型のタスクを実行するための計算リソースおよびストレージリソースを提供する分散型プラットフォームと考えることができる。
いくつかの例では、ＩｏＴデバイス５１０２は、命令型プログラミングスタイルを使用して、例えば、各ＩｏＴデバイス５１０２が特定の機能および通信パートナーを有するように構成され得る。しかしながら、フォグデバイスを形成するＩｏＴデバイス５１０２は、宣言型プログラミングスタイルで構成され得、ＩｏＴデバイス５１０２が、条件、クエリ、およびデバイス故障に応答して必要なリソースを決定するなどのためにそれらのオペレーションをよび通信を再構成することを可能にする。例として、ＩｏＴデバイス５１０２によって監視される機器のサブセットのオペレーションに関する、サーバ５１０６に位置するユーザからのクエリは、クエリに回答するために必要な特定のセンサ５１２８などのＩｏＴデバイス５１０２を選択するフォグ５１２０デバイスをもたらし得る。次に、これらのセンサ５１２８からのデータは、センサ５１２８、データアグリゲータ５１２６、またはゲートウェイ５１０４の任意の組み合わせによって集約され、分析され得てから、フォグ５１２０デバイスによってサーバ５１０６に送信され、クエリに回答する。この例では、フォグ５１２０内のＩｏＴデバイス５１０２は、フローセンサまたは温度センサからのデータを追加するなど、クエリに基づいて使用されるセンサ５１２８を選択し得る。さらに、ＩｏＴデバイス５１０２のいくつかが動作していない場合、フォグ５１２０デバイス内の他のＩｏＴデバイス５１０２は、使用可能な場合、類似のデータを提供し得る。
例では、作業負荷オーケストレーションおよびオペレーションの様々な態様は、図５１に示される様々なネットワークトポロジおよび手法に適合され得る。例えば、システムは、ＩｏＴデバイス５１０２と連携してクラウド５１００で実行される様々な作業負荷を確立し得る。これらの作業負荷は、クラウド５１００またはフォグ５１２０でエッジから（例えば、ＩｏＴデバイス５１０２から）オーケストレートされ得る。または、このような作業負荷は、クラウド５１００またはフォグ５１２０によってエッジでオーケストレートされ得る。このような概念は、ゲートウェイ５１０４およびデータアグリゲータ５１２６、ならびにネットワークトポロジ内の他のデバイスおよびノードにも適用され得る。
他の例では、上で説明されたシステムを参照して上で説明されたオペレーションおよび機能は、電子処理システムの例の形のＩｏＴデバイスマシンによって具現化され得、ある例によれば、その中で、命令のセットまたはシーケンスが実行されて、電子処理システムに、本明細書で論じられる方法論のうちのいずれか１つを実行させることができる。機械は、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、携帯情報端末（ＰＤＡ）、携帯電話またはスマートフォンの態様によって具現化される機械、またはその機械が実行する動作を指定する命令（シーケンシャルまたはその他）を実行できる任意の機械を含むＩｏＴデバイスまたはＩｏＴゲートウェイであり得る。さらに、上記の例では単一の機械のみを示し、参照し得るが、このような機械は、１つ（または複数）の命令セットを個別または共同で実行して、本明細書で説明する方法論のうちのいずれか１つまたは複数を実行する機械のコレクションも含むものとする。さらに、プロセッサに基づくシステムのこれらおよび同様の例は、プロセッサ（例えば、コンピュータ）によって制御または動作される１つまたは複数の機械の任意のセットを含むと解釈されるものとし、本明細書で論じられる方法論のうちのいずれか１つまたは複数を実行するための命令を個別にまたは共同で実行する。
図５２は、いくつかのモノのインターネット（ＩｏＴ）デバイスと通信するクラウドコンピューティングネットワークまたはクラウド５２００の図を示す。クラウド５２００は、インターネットを表し得るか、ローカルエリアネットワーク（ＬＡＮ）、または企業の独自のネットワークなどのワイドエリアネットワーク（ＷＡＮ）であり得る。ＩｏＴデバイスは、様々な組み合わせでグループ化された、任意の数の異なるタイプのデバイスを含み得る。例えば、トラフィック制御グループ５２０６は、都市の道路に沿ったＩｏＴデバイスを含み得る。これらのＩｏＴデバイスは、信号機、トラフィックフローモニタ、カメラ、気象センサなどを含み得る。トラフィック制御グループ５２０６または他のサブグループは、ＬＰＷＡリンク、光リンクなどの有線または無線リンク５２０８を介してクラウド５２００と通信し得る。さらに、有線または無線サブネットワーク５２１２は、ＩｏＴデバイスが、ローカルエリアネットワーク、無線ローカルエリアネットワークなどを介してなど、相互に通信することを可能にし得る。ＩｏＴデバイスは、ゲートウェイ５２１０または５２２８などの別のデバイスを使用して、クラウド５２００などの遠隔地と通信し得る。ＩｏＴデバイスはまた、１つまたは複数のサーバ５２３０を使用して、クラウド５２００またはゲートウェイ５２１０との通信を促進し得る。例えば、１つまたは複数のサーバ５２３０は、ローカルエリアネットワーク間のローカルエッジクラウドまたはフォグ実装をサポートするための中間ネットワークノードとして動作し得る。さらに、描かれているゲートウェイ５２２８は、クラウドからゲートウェイへの多数のエッジデバイス構成で動作することができ、例えば、様々なＩｏＴデバイス５２１４、５２２０、５２２４は、クラウド５２００内のリソースの割り当ておよび使用に制約されるか、または動的である。
ＩｏＴデバイスの他の例のグループは、特に、遠隔気象ステーション５２１４、ローカル情報端末５２１６、アラームシステム５２１８、現金自動預払機５２２０、アラームパネル５２２２、または緊急車両５２２４または他の車両５２２６などの移動車両を含み得る。これらのＩｏＴデバイスの各々は、他のＩｏＴデバイス、サーバ５２０４、別のＩｏＴフォグデバイスまたはシステム（図示しないが、図５１に示されている）、またはそれらの組み合わせと通信し得る。ＩｏＴデバイスのグループは、様々な住宅、商業、および産業の設定（プライベートおよびパブリック環境の両方を含む）で配置できる。
図５２から分かるように、多数のＩｏＴデバイスがクラウド５２００を通じて通信し得る。これにより、様々なＩｏＴデバイスが自動的に他のデバイスに情報を要求または提供できる。例えば、ＩｏＴデバイスのグループ（例えば、トラフィック制御グループ５２０６）は、人間の介入なしに予測を提供し得る遠隔気象ステーション５２１４のグループからの現在の天気予報を要求し得る。さらに、緊急車両５２２４は、強盗が進行中であることを現金自動預払機５２２０によって警告され得る。緊急車両５２２４が現金自動預払機５２２０に向かって進むと、それは、例えば、緊急車両５２２４が交差点への邪魔されないアクセスを有するのに十分な時間内に交差点での交差トラフィックを遮断するためにライトが赤に変わることによってトラフィック制御グループ５２０６にアクセスしてその場所への通関を要求し得る。
遠隔気象ステーション５２１４またはトラフィック制御グループ５２０６などのＩｏＴデバイスのクラスタは、他のＩｏＴデバイスおよびクラウド５２００と通信するように装備され得る。これは、ＩｏＴデバイスがデバイス間にアドホックネットワークを形成することを可能にし得、それらが単一デバイスとして機能することを可能にし、これはフォグデバイスまたはシステムと呼ばれ得る（例えば、図５１を参照して上述したように）。
図５３は、本明細書で説明される技術を実装するためのＩｏＴデバイス５３５０に存在し得るコンポーネントの例のブロック図である。ＩｏＴデバイス５３５０は、例に示されるか、または上記の開示で参照されるコンポーネントの任意の組み合わせを含み得る。コンポーネントは、ＩＣ、その一部、個別の電子デバイス、または他のモジュール、ロジック、ハードウェア、ソフトウェア、ファームウェア、またはＩｏＴデバイス５３５０に適合したそれらの組み合わせとして、あるいは他の大きなシステムのシャーシ内に組み込まれたコンポーネントとして実装できる。さらに、図５３のブロック図は、ＩｏＴデバイス５３５０のコンポーネントの高レベルのビューを示すことを意図している。しかしながら、図示されたコンポーネントのいくつかは省略され得、追加のコンポーネントが存在し得、図示されたコンポーネントの異なる配置が他の実装で生じ得る。
ＩｏＴデバイス５３５０は、マイクロプロセッサ、マルチコアプロセッサ、マルチスレッドプロセッサ、超低電圧プロセッサ、埋め込みプロセッサ、または他の既知の処理要素であり得るプロセッサ５３５２を含み得る。プロセッサ５３５２は、プロセッサ５３５２および他のコンポーネントが単一集積回路、またはインテルのエジソン（登録商標）またはガリレオ（登録商標）ＳｏＣボードなどの単一パッケージに形成されるシステムオンチップ（ＳｏＣ）の一部であり得る。例として、プロセッサ５３５２はＱｕａｒｋ（登録商標）、Ａｔｏｍ（登録商標）、ｉ３、ｉ５、ｉ７などのＩｎｔｅｌ（登録商標）Ａｒｃｈｉｔｅｃｔｕｒｅ Ｃｏｒｅ（登録商標）基づくプロセッサまたはＭＣＵクラスのプロセッサ、またはカリフォルニア州サンタクララのＩｎｔｅｌ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎから入手可能なその他のプロセッサを含み得る。ただし、任意の数の他のプロセッサが使用されてよく、そのようなプロセッサは、カリフォルニア州サニーベールのＡｄｖａｎｃｅｄ Ｍｉｃｒｏ Ｄｅｖｉｃｅｓ，Ｉｎｃ．（ＡＭＤ）、カリフォルニア州サニーベールのＭＩＰＳ Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．のＭＩＰＳベースの設計品、ＡＲＭ Ｈｏｌｄｉｎｇｓ，Ｌｔｄ．もしくはその顧客からライセンス供与されたＡＲＭベースの設計品、またはそのライセンシもしくは利用者から入手可能である。プロセッサは、Ａｐｐｌｅ（登録商標）Ｉｎｃ．のＡ５−Ａ１０プロセッサ、Ｑｕａｌｃｏｍｍ（登録商標）Ｔｅｃｈｎｏｌｏｇｉｅｓ，Ｉｎｃ．のＳｎａｐｄｒａｇｏｎ（登録商標）プロセッサ、Ｔｅｘａｓ Ｉｎｓｔｒｕｍｅｎｔｓ，Ｉｎｃ．のＯＭＡＰ（登録商標）プロセッサなどのユニットを含み得る。
プロセッサ５３５２は、相互接続５３５６（例えば、バス）を介してシステムメモリ５３５４と通信し得る。任意の数のメモリデバイスを使用して、特定の量のシステムメモリを提供し得る。例として、メモリは、ＤＤＲまたはモバイルＤＤＲ標準（例えば、ＬＰＤＤＲ、ＬＰＤＤＲ２、ＬＰＤＤＲ３、ＬＰＤＤＲ４）などの共同電子デバイス工学評議会（Ｊｏｉｎｔ Ｅｌｅｃｔｒｏｎ Ｄｅｖｉｃｅｓ Ｅｎｇｉｎｅｅｒｉｎｇ Ｃｏｕｎｃｉｌ）（ＪＥＤＥＣ）設計に準拠したランダムアクセスメモリ（ＲＡＭ）であり得る。様々な実装において、個々のメモリデバイスは、単一ダイパッケージ（ＳＤＰ）、デュアルダイパッケージ（ＤＤＰ）またはクワッドダイパッケージ（Ｑ１７Ｐ）などの任意の数の異なるパッケージタイプであり得る。これらのデバイスは、一部の例ではマザーボードに直接はんだ付けして低プロファイルのソリューションを提供するが、他の例では、デバイスは１つまたは複数のメモリモジュールとして構成され、次いで、所定のコネクタによってマザーボードに結合される。例えば、ｍｉｃｒｏＤＩＭＭやＭｉｎｉＤＩＭＭを含むがこれらに限定されない、様々な種類のデュアルインラインメモリモジュール（ＤＩＭＭ）など、他のタイプのメモリモジュールなど、任意の数の他のメモリ実装を使用できる。
データ、アプリケーション、オペレーティングシステムなどの情報の永続的なストレージを提供するために、ストレージ５３５８は、相互接続５３５６を介してプロセッサ５３５２に結合することもできる。例では、ストレージ５３５８は、ソリッドステートディスクドライブ（ＳＳＤＤ）を介して実装され得る。ストレージ５３５８に使用され得る他のデバイスは、ＳＤカード、ｍｉｃｒｏＳＤカード、ｘＤピクチャカードなどのフラッシュメモリカード、およびＵＳＢフラッシュドライブを含む。低電力の実装では、ストレージ５３５８は、プロセッサ５３５２に関連するオンダイメモリまたはレジスタであり得る。しかしながら、いくつかの例では、ストレージ５３５８は、マイクロハードディスクドライブ（ＨＤＤ）を使用して実装され得る。さらに、特に、抵抗変化メモリ、相変化メモリ、ホログラフィックメモリ、または化学メモリなど、説明した技術に加えて、またはその代わりに、任意の数の新しい技術をストレージ５３５８に使用し得る。
コンポーネントは、相互接続５３５６を介して通信できる。相互接続５３５６は任意の数の技術を含んでよく、これらの技術には、業界標準アーキテクチャ（ＩＳＡ）、拡張ＩＳＡ（ＥＩＳＡ）、周辺コンポーネント相互接続（ＰＣＩ）、周辺コンポーネント相互接続拡張（ＰＣＩｘ）、ＰＣＩエクスプレス（ＰＣＩｅ）、または任意の数の他の技術が含まれる。相互接続５３５６は、例えば、ＳｏＣに基づくシステムで使用される独自のバスであり得る。特に、Ｉ２Ｃインタフェース、ＳＰＩインタフェース、ポイントツーポイントインタフェース、および電源バスなど、他のバスシステムが含まれ得る。
相互接続５３５６は、他のメッシュデバイス５３６４との通信のために、プロセッサ５３５２をメッシュトランシーバ５３６２に結合し得る。メッシュトランシーバ５３６２は、特に、ブルートゥース（登録商標）Ｓｐｅｃｉａｌ Ｉｎｔｅｒｅｓｔ Ｇｒｏｕｐによって定義されたブルートゥース（登録商標）低エネルギー（ＢＬＥ）標準、またはＺｉｇＢｅｅ（登録商標）標準を使用するＩＥＥＥ ８０２．１５．４標準に基づく２．４ギガヘルツ（ＧＨｚ）伝送など、任意の数の周波数とプロトコルを使用できる。特定の無線通信プロトコル用に構成された任意の数の無線を、メッシュデバイス５３６４への接続に使用し得る。例えば、ＷＬＡＮユニットは、米国電気電子学会（Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）（ＩＥＥＥ）８０２．１１標準に従ってＷｉ−Ｆｉ（登録商標）通信を実装するために使用され得る。さらに、例えば、セルラーまたは他の無線ワイドエリアプロトコルによる無線ワイドエリア通信は、ＷＷＡＮユニットを介して行われ得る。
メッシュトランシーバ５３６２は、異なる範囲での通信のために複数の標準または無線を使用して通信し得る。例えば、ＩｏＴデバイス５３５０は、ＢＬＥまたは別の低電力無線に基づくローカルトランシーバを使用して、電力を節約するために、例えば約１０メートル以内で、近くのデバイスと通信し得る。例えば約５０メートル以内のより遠いメッシュデバイス５３６４は、ＺｉｇＢｅｅまたは他の中間電力無線を介して到達され得る。両方の通信技術は、異なる電力レベルで単一無線を介して行われるか、または、例えば、ＢＬＥを使用するローカルトランシーバやＺｉｇＢｅｅを使用する別のメッシュトランシーバなど、別のトランシーバを介して実行され得る。
無線ネットワークトランシーバ５３６６は、ローカルまたはワイドエリアネットワークプロトコルを介してクラウド５３００内のデバイスまたはサービスと通信するために含まれ得る。無線ネットワークトランシーバ５３６６は、特に、ＩＥＥＥ８０２．１５．４、またはＩＥＥＥ８０２．１５．４ｇ標準に従うＬＰＷＡトランシーバであり得る。ＩｏＴデバイス５３５０は、ＳｅｍｔｅｃｈおよびＬｏＲａ Ａｌｌｉａｎｃｅによって開発されたＬｏＲａＷＡＮ（登録商標）（ロングレンジワイドエリアネットワーク）を使用してワイドエリアで通信できる。本明細書で説明する技術は、これらの技術に限定されず、Ｓｉｇｆｏｘなどの他の長距離低帯域幅通信を実装する他の任意の数のクラウドトランシーバや他の技術と共に使用され得る。さらに、ＩＥＥＥ８０２．１５．４ｅ仕様に記載されているタイムスロット化チャネルホッピングなどの他の通信技術を使用し得る。
本明細書で説明するように、メッシュトランシーバ５３６２および無線ネットワークトランシーバ５３６６について述べたシステムに加えて、他の任意の数の無線通信およびプロトコルを使用し得る。例えば、無線トランシーバ５３６２および５３６６は、高速通信を実装するためにスペクトル拡散（ＳＰＡ／ＳＡＳ）通信を使用するＬＴＥまたは他のセルラートランシーバを含み得る。さらに、中速通信およびネットワーク通信の提供のためのＷｉ−Ｆｉ（登録商標）ネットワークなど、他の任意の数のプロトコルを使用し得る。
無線トランシーバ５３６２および５３６６は、任意の数の３ＧＰＰ（第３世代パートナーシッププロジェクト）仕様、特にロングタームエボリューション（ＬＴＥ）、ロングタームエボリューション−アドバンスド（ＬＴＥ−Ａ）、およびロングタームエボリューション−アドバンスドプロ（ＬＴＥ−Ａ Ｐｒｏ）と互換性のある無線を含み得る。他の任意の数の固定、移動、または衛星通信技術および標準と互換性のある無線を選択できることに留意されたい。これらは、例えば、セルラーワイドエリア無線通信技術を含み得、これは、例えば第５世代（５Ｇ）通信システム、グローバルシステムフォーモービルコミュニケーションズ（ＧＳＭ（登録商標））無線通信技術、汎用パケット無線サービス（ＧＰＲＳ）無線通信技術、またはＧＳＭ進化（ＥＤＧＥ）無線通信技術の拡張データレート、ＵＭＴＳ（ユニバーサル移動体通信システム）通信技術を含み得、上記の標準に加えて、特に、例えば、ＩＴＵ（国際電気通信連合）またはＥＴＳＩ（欧州通信規格機構）などが発行した規格に準拠した無線を含む、任意の数の衛星アップリンク技術を無線ネットワークトランシーバ５３６６に使用できる。したがって、本明細書で提供される例は、既存の、およびまだ計画策定されていない、他の様々な通信技術に適用可能であると理解される。
ネットワークインタフェースコントローラ（ＮＩＣ）５３６８は、クラウド５３００またはメッシュデバイス５３６４などの他のデバイスへの有線通信を提供するために含まれ得る。有線通信は、イーサネット接続を提供し得るか、多くの中からコントローラエリアネットワーク（ＣＡＮ）、ローカル相互接続ネットワーク（ＬＩＮ）、ＤｅｖｉｃｅＮｅｔ、ＣｏｎｔｒｏｌＮｅｔ、Ｄａｔａ Ｈｉｇｈｗａｙ＋、ＰＲＯＦＩＢＵＳ、ＰＲＯＦＩＮＥＴなど、他のタイプのネットワークに基づき得る。例えば、イーサネットを介してクラウドへの通信を提供するＮＩＣ ５３６８や、別のタイプのネットワークを経由して他のデバイスへの通信を提供する第２ＮＩＣ ５３６８など、第２ネットワークへの接続を可能にする追加のＮＩＣ５３６８を含めることができる。
相互接続５３５６は、プロセッサ５３５２を、外部デバイスまたはサブシステムを接続するために使用される外部インタフェース５３７０に結合し得る。外部デバイスは、加速度計、レベルセンサ、フローセンサ、光学光センサ、カメラセンサ、温度センサ、全地球測位システム（ＧＰＳ）センサ、圧力センサ、気圧センサなどのセンサ５３７２を含み得る。外部インタフェース５３７０をさらに使用して、ＩｏＴデバイス５３５０を、電源スイッチ、バルブアクチュエータ、可聴音発生器、視覚警告デバイスなどのアクチュエータ５３７４に接続し得る。
いくつかのオプションの例では、様々な入力／出力（Ｉ／Ｏ）デバイスがＩｏＴデバイス５３５０内に存在するか、ＩｏＴデバイス５３５０に接続され得る。例えば、ディスプレイまたは他の出力デバイス５３８４は、センサの読み取り値またはアクチュエータの位置などの情報を示すために含まれ得る。入力を受け入れるために、タッチ画面またはキーパッドなどの入力デバイス５３８６を含めることができる。出力デバイス５３８４は、バイナリステータスインジケータ（例えば、ＬＥＤ）および複数文字の視覚出力のような単純な視覚出力や、またはディスプレイ画面（例えば、ＬＣＤ画面）などのより複雑な出力を含む、任意の数の形式のオーディオまたは視覚ディスプレイを含むことができ、文字、グラフィックス、マルチメディアオブジェクトなどの出力が、ＩｏＴデバイス５３５０のオペレーションから生成または生産される。
バッテリー５３７６は、ＩｏＴデバイス５３５０に電力を供給し得るが、ＩｏＴデバイス５３５０が固定位置に取り付けられる例では、それは、送電網に結合された電源を有し得る。バッテリー５３７６は、リチウムイオンバッテリー、または亜鉛空気バッテリー、アルミニウム空気バッテリー、リチウム空気バッテリーなどの金属空気バッテリーであり得る。
バッテリー５３７６の充電状態（ＳｏＣｈ）を追跡するために、バッテリーモニタ／充電器５３７８をＩｏＴデバイス５３５０に含めることができる。バッテリーモニタ／充電器５３７８は、バッテリー５３７６の他のパラメータを監視して、バッテリー５３７６の正常性の状態（ＳｏＨ）や機能状態（ＳｏＦ）などの故障予測を提供するために使用できる。バッテリーモニタ／充電器５３７８は、リニア技術社のＬＴＣ４０２０またはＬＴＣ２９９０、アリゾナ州フェニックスのＯＮ半導体のＡＤＴ７４８８Ａ、テキサス州ダラスのテキサスインスツルメンツのＵＣＤ９０ｘｘｘファミリーのＩＣなどのバッテリー監視集積回路を含み得る。バッテリーモニタ／充電器５３７８は、相互接続５３５６を介してバッテリー５３７６上の情報をプロセッサ５３５２に通信し得る。バッテリーモニタ／充電器５３７８はまた、プロセッサ５３５２がバッテリー５３７６の電圧またはバッテリー５３７６からの電流フローを直接監視することを可能にするアナログ−デジタル（ＡＤＣ）コンバータを含み得る。バッテリーパラメータは、送信周波数、メッシュネットワークオペレーション、感知周波数などのような、ＩｏＴデバイス５３５０が実行し得る動作を決定するために使用され得る。
電力ブロック５３８０、またはグリッドに結合された他の電源は、バッテリー５３７６を充電するためにバッテリーモニタ／充電器５３７８と結合され得る。いくつかの例では、電力ブロック５３８０は、例えば、ＩｏＴデバイス５３５０内のループアンテナを介して無線で電力を取得するために、無線電力受信機と置き換えられ得る。特に、カリフォルニア州ミルピタスのリニア技術社のＬＴＣ４０２０チップなどの無線バッテリー充電回路が、バッテリーモニタ／充電器５３７８に含まれ得る。選択される特定の充電回路は、バッテリー５３７６のサイズ、したがって必要な電流によって異なる。充電は、特に、Ａｉｒｆｕｅｌ Ａｌｌｉａｎｃｅによって公布されたＡｉｒｆｕｅｌ標準、Ｗｉｒｅｌｅｓｓ Ｐｏｗｅｒ Ｃｏｎｓｏｒｔｉｕｍによって公布されたＱｉ無線充電標準、またはＡｌｌｉａｎｃｅ ｆｏｒ Ｗｉｒｅｌｅｓｓ Ｐｏｗｅｒによって公布されたＲｅｚｅｎｃｅ充電標準を使用して実行できる。
ストレージ５３５８は、本明細書で説明される技術を実装するためのソフトウェア、ファームウェア、またはハードウェアコマンドの形の命令５３８２を含み得る。このような命令５３８２は、メモリ５３５４およびストレージ５３５８に含まれるコードブロックとして示されているが、コードブロックのいずれも、例えば特定用途向け集積回路（ＡＳＩＣ）に組み込まれたハードワイヤード回路で置き換えられ得ることが理解され得る。
例では、メモリ５３５４、ストレージ５３５８、またはプロセッサ５３５２を介して提供される命令５３８２は、プロセッサ５３５２にＩｏＴデバイス５３５０で電子オペレーションを実行するように指示するコードを含む非一時的な機械可読媒体５３６０として具現化され得る。プロセッサ５３５２は、相互接続５３５６を介して非一時的な機械可読媒体５３６０にアクセスし得る。例えば、非一時的な機械可読媒体５３６０は、図５３のストレージ５３５８について説明されたデバイスによって具現化され得、または、光ディスク、フラッシュドライブ、または任意の数のその他のハードウェアデバイスなど、特定のストレージユニットを含み得る。非一時的な機械可読媒体５３６０は、例えば、上記のオペレーションおよび機能のフローチャートとブロック図に関して説明されるように、特定のシーケンスまたは動作のフローを実行するようにプロセッサ５３５２に指示する命令を含み得る。
さらなる例では、機械可読媒体は、あらゆる有形の媒体も含み、機械による実行のための命令を保存、エンコード、または運ぶことができ、機械に本開示の方法論のうちのいずれか１つまたは複数を実行させるか、またはこのような命令によって利用されるか、または関連するデータ構造を保存、エンコード、または運ぶことができる。したがって、「機械可読媒体」は、限定ではないが、固体メモリ、ならびに光学媒体および磁気媒体を含み得る。機械可読媒体の特定の例は、例として、半導体メモリデバイス（例えば、電気的にプログラマブル読み取り専用メモリ（ＥＰＲＯＭ）、電気的に消去可能なプログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ））およびフラッシュメモリデバイス、内蔵ハードディスクやリムーバブルディスクなどの磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭおよびＤＶＤ−ＲＯＭディスクを含むがこれらに限定されない不揮発性メモリを含む。機械可読媒体によって具現化される命令は、いくつかの転送プロトコル（例えば、ＨＴＴＰ）のうちのいずれか１つを利用するネットワークインタフェースデバイスを介して、伝送媒体を使用して通信ネットワークを経由してさらに送信または受信され得る。
本明細書で説明される機能ユニットまたは機能は、それらの実装の独立性をより具体的に強調するために、コンポーネントまたはモジュールと呼ばれ、またはラベル付けされ得ることを理解されたい。このようなコンポーネントは、任意の数のソフトウェアまたはハードウェアの形態で具現化され得る。例えば、コンポーネントまたはモジュールは、カスタムの超大規模集積（ＶＬＳＩ）回路またはゲートアレイを含むハードウェア回路、ロジックチップ、トランジスタなどの既製の半導体、または他の個別のコンポーネントとして実装され得る。コンポーネントまたはモジュールは、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジックデバイスなどのプログラマブルハードウェアデバイスでも実装され得る。コンポーネントまたはモジュールはまた、様々なタイプのプロセッサによる実行のためにソフトウェアで実装され得る。実行可能コードの識別されたコンポーネントまたはモジュールは、例えば、オブジェクト、手順、または機能として組織化され得る、コンピュータ命令の１つまたは複数の物理的またはロジック的ブロックを含み得る。それにもかかわらず、識別されたコンポーネントまたはモジュールの実行可能ファイルは物理的に一緒に配置する必要はないが、論理的に一緒に結合する場合、コンポーネントまたはモジュールを含み、コンポーネントまたはモジュールの上記の目的を実現する様々な場所に保存された異なる命令を含み得る。
実際、実行可能コードのコンポーネントまたはモジュールは、単一命令または多くの命令であり得、いくつかの異なるコードセグメントにわたって、異なるプログラム間で、およびいくつかのメモリデバイスまたは処理システムにわたって分散され得る。特に、説明されているプロセスのいくつかの態様（コードの書き換えやコードの分析など）は、コードが配置されている処理システム（例えば、センサやロボットに埋め込まれたコンピュータ）とは異なる処理システム（例えば、データセンター内のコンピュータ）で行われ得る。同様に、動作データは、本明細書ではコンポーネントまたはモジュール内で識別および示すことができ、任意の適切な形式で具現化され、任意の適切なタイプのデータ構造内で組織化され得る。動作データは、単一データセットとして収集することも、異なるストレージデバイスを含む異なる場所に分散することもでき、少なくとも部分的には、単にシステムまたはネットワーク上の電子信号として存在し得る。コンポーネントまたはモジュールは、所望の機能を実行するように動作可能なエージェントを含む、受動的または有効であり得る。
［例］
［例］
現在説明されている方法、システム、およびデバイスの実施形態の追加の例は、以下の非限定的な構成を含む。以下の非限定的な例の各々は、それ自体で成り立ち得るか、任意の順列または以下または本開示全体にわたって提供される他の例のうちのいずれか１つまたは複数と組み合わせて組み合わせられ得る。
例１は、ソフトウェア定義型産業システムのオペレーションのための方法であり、ソフトウェア定義型産業システムのそれぞれの機能定義を確立する段階を含み、ソフトウェア定義型産業システムは、複数のデバイスとインタフェースし、複数のデバイスは、それぞれのセンサおよびそれぞれのアクチュエータを含み、そして、それぞれの機能定義を使用してソフトウェア定義型産業システムを動作する段階を含む。
例２では、例１の主題は、動的データモデルを確立して、ソフトウェア定義型産業システムの複数のコンポーネントの特性を定義する段階と、複数のコンポーネントに関連するオペレーションメタデータに基づいて動的データモデルを更新する段階とを含む。
例３では、例２の主題は、複数のコンポーネントは、それぞれのアプリケーション、デバイス、センサ、またはアーキテクチャ定義を含むことを含む。
例４では、例２〜３の主題は、複数のコンポーネントが装置を含み、デバイスがセンサの集合を表すことを含む。
例５では、例２〜４の主題は、動的データモデルは、複数のコンポーネントのうちのコンポーネントのサブセットにおける動的データモデルへの変更を示すように更新され、動的データモデルは、コンポーネントのサブセットで発生するリソース可用性の変化またはエラー条件に基づいて更新されることを含む。
例６では、例２〜５の主題は、動的データモデルを確立する段階は、動的データモデルへの変更の必須フィールドと制限を定義する段階を含むことを含む。
例７では、例２〜６の主題は、動作メタデータが、複数のコンポーネントのうちのあるコンポーネントに関連する値の確率論的推定を表すことを含む。
例８では、例２〜７の主題は、複数のコンポーネントのうちのあるコンポーネントにメタデータ拡張ルールをクエリする段階と、クエリする段階に応答してコンポーネントから応答を受信する段階とを含み、動的データモデルの更新はさらに、メタデータ拡張ルール、およびそれぞれのデータフィールドの更新に関連する信頼性または関連性スコアに基づく。
例９では、例２〜８の主題は、複数のコンポーネントからのデータフローを監視して動作メタデータを識別する段階と、複数のコンポーネントから１つまたは複数のパターンを検出する段階と、検出された１つまたは複数のパターンに基づいて動的データモデルへの変更を識別する段階とを含み、動的データモデルの更新は、識別された変更を組み込む段階を含む。
例１０では、例２〜９の主題は、更新された動的データモデルに基づいて、エッジ、フォグ、またはクラウドネットワークでシステムオペレーションを実行する段階を含む。
例１１では、例１〜１０の主題は、データモデル評価のためのソフトウェア定義型産業システムで少なくとも１つの条件を定義する段階と、ソフトウェア定義型産業システムの複数のセンサからデータを取得する段階と、データモデルを修正するための少なくとも１つのパターン、ルール、または閾値を識別する段階と、少なくとも１つの識別されたパターン、ルール、または識別された閾値を使用して、複数のセンサからのデータを評価する段階と、少なくとも１つの識別されたパターン、ルール、または識別された閾値に基づいて、データモデルの修正を定義する段階と、複数のセンサおよび複数のセンサに関連するデータフローのためのデータモデルへの修正を組み込む段階とを含む。
例１２では、例１１の主題は、データモデル管理者にデータモデル修正の承認を要求する段階と、データモデル管理者からデータモデル修正の承認を受信する段階とを含み、データモデルへの修正の組み込みは、データモデル修正の承認の受信に応答して実行される。
例１３では、例１１〜１２の主題は、データモデル修正に基づくソフトウェア定義型産業システムでのデータ処理オペレーションへの変更を実装する段階を含む。
例１４では、例１〜１３の主題は、ソフトウェア定義型産業システム内のリソースの分散型リソースプール全体で実行される機能ブロックの拡張されたオーケストレータロジックルールセットを確立する段階を含む。
例１５では、例１４の主題は、ネットワーク帯域幅、リソース容量、現在の状態、および分散型リソースプールの制御アプリケーション制約の動的発見を実行する段階を含む。
例１６では、例１４〜１５の主題は、それぞれのレガシーアプリケーションとインタフェースするシムを介して、それぞれのレガシーデバイスとのオーケストレーションを確立する段階を含む。
例１７では、例１４〜１６の主題は、拡張されたオーケストレータルールセットは、アプリケーションサイクル時間、アプリケーションランタイム、アプリケーション入力／出力信号依存性、またはアプリケーションプロセス順序のうちの１つまたは複数を含むことを含む。
例１８では、例１４〜１７の主題は、アプリケーションサイクル、アプリケーション配置のランタイムの依存性、およびアプリケーション配置の現在の状態に基づいて、アプリケーション配置の機能ブロックアプリケーションのタイミング依存性を評価する段階と、評価された機能ブロックのアプリケーションのタイミング依存性に基づいて、ソフトウェア定義型産業システムのノード間でアプリケーション配置のそれぞれのアプリケーションを分散する段階とを含む。
例１９では、例１４〜１８の主題は、アプリケーション配置のそれぞれの機能ブロックを監視する段階と、現在および過去のデータに基づいて最適化と予測の予報を更新する段階と、それぞれの機能ブロックのうちの１つまたは複数からのシステム異常の検出に応答して、制御戦略に従って分散型リソースプール内のそれぞれの機能ブロックのうちの１つまたは複数の実行をオーケストレートする段階とを含む。
例２０では、例１９の主題は、制御戦略が実行可能であるかどうかを判断する段階を含み、制御戦略が実行可能であると判断したことに応答して、それぞれの機能ブロックのうちの１つまたは複数の実行をオーケストレートすることが実行可能でSル。
例２１では、例２０の主題は、制御戦略が実行不可能であるとの判断に応答して、それぞれの機能ブロックのうちの１つまたは複数の少なくとも一部に対して低下または切断制御戦略を実装する段階を含む。
例２２では、例１４〜２１の主題は、分散型リソースプールは、追加のネイティブデバイスで第２冗長アプリケーションが使用可能である単一ネイティブデバイスで実行される単一アプリケーション、複数のネイティブデバイスで実行される複数の連携されたアプリケーション、仮想マシンは単一組み込みデバイスまたはサーバで実行されている単一仮想マシンで実行されている複数の連携されたアプリケーション、各仮想マシンは専用の組み込みデバイスまたはサーバで実行される、複数の仮想マシンにわたって実行される複数の連携されたアプリケーション、各仮想マシンが専用の組み込みデバイスまたはサーバで実行される１つの仮想マシンに含まれる複数のコンテナにまたがる複数の連携されたアプリケーション、または、コンテナが複数の組み込みデバイスまたはサーバで実行されている複数のコンテナにまたがる複数の連携されたアプリケーションのうちの１つまたは複数にまたがるアプリケーションを包含することを含む。
例２３では、例１４〜２２の主題は、リソースの分散型リソースプール全体で実行される機能ブロックに対して、拡張されたオーケストレータロジックルールセットを確立する段階を含み、アプリケーション固有の依存性を識別する段階と、識別された依存性に基づいて、分散型および依存型アプリケーションのオーケストレーショングループを動的に作成する段階と、オーケストレーションイベントを予測する段階と、予測されたオーケストレーションイベントを検出する段階と、予測されたオーケストレーションイベントの検出に応答してリソース配置を最適化する段階とを含む。
例２４では、例２３の主題は、オーケストレーションイベントを予測する段階は、例示的なシナリオにおけるネットワーク帯域幅を動的に分析およびシミュレーションする段階と、例示的なシナリオにおけるオーケストレーションイベントの発生を分析する段階とを含むことを含む。
例２５では、例１〜２４の主題は、レガシーコンポーネントとの通信を確立する段階であって、レガシーコンポーネントは、レガシーソフトウェアモジュールまたはレガシーハードウェアデバイスである、段階と、オーケストレーション可能なコンポーネントとの通信を確立する段階であって、オーケストレーション可能なコンポーネントは、オーケストレーション可能なソフトウェアモジュールまたはオーケストレーション可能なハードウェアデバイスである、段階と、オーケストレーション可能なコンポーネントとレガシーコンポーネント間で作業負荷を制御および分散するための組織化されたオーケストレーションを確立する段階とを含む。
例２６では、例２５の主題は、レガシーソフトウェアモジュールを構成するオーケストレーションシムを確立する段階であって、オーケストレーションシムは、レガシーソフトウェアモジュールにカスタム構成を提供するように適合される、段階と、作業負荷の制御と分散のために、カスタム構成に基づいてレガシーソフトウェアモジュールと直接通信する段階とを含む。
例２７では、例２６の主題は、オーケストレーションシムのアプリケーションプログラミングインタフェース（ＡＰＩ）を介してレガシーソフトウェアモジュールにカスタム構成を通信する段階と、オーケストレーションシムのＡＰＩを介してレガシーソフトウェアモジュールからレガシーモジュール通信情報を通信する段階とを含み、レガシーソフトウェアモジュールとの通信は、レガシーモジュール通信情報を使用してさらに実行される。
例２８では、例２６〜２７の主題は、オーケストレーションソフトウェアモジュールのアプリケーションプログラミングインタフェース（ＡＰＩ）を介してオーケストレーション可能なソフトウェアモジュールに、第２構成を通信する段階と、作業負荷の制御および分散のために、第２構成に基づいてオーケストレーション可能なソフトウェアモジュールと直接通信する段階とを含む。
例２９では、例２５〜２８の主題は、レガシーハードウェアデバイスの使用可能なリソースを示すオーケストレーション可能なハードウェアデバイスのエージェントから収集されたテレメトリに基づいて、オーケストレーション可能なハードウェアデバイスを介してレガシーハードウェアデバイスとの組織化されたオーケストレーションを確立する段階と、組織化されたオーケストレーションに基づく作業負荷を、オーケストレーション可能なハードウェアデバイスのエージェントを介してレガシーハードウェアデバイスに配置する段階とを含む。
例３０では、例２５〜２９の主題は、オーケストレーション可能なハードウェアデバイスの使用可能なリソースを示すオーケストレーション可能なハードウェアデバイスのエージェントから収集されたテレメトリに基づいて、オーケストレーション可能なハードウェアデバイスを使用して組織化されたオーケストレーションを確立する段階と、組織化されたオーケストレーションに基づく作業負荷を、オーケストレーション可能なハードウェアデバイスのエージェントを介してオーケストレーション可能なハードウェアデバイスに配置する段階とを含む。
例３１では、例２５〜３０の主題は、オーケストレータのオーケストレーションエンジンで、それぞれのオーケストレーション可能なデバイスから使用可能なリソースの説明を受信する段階であって、使用可能なリソースの説明は、それぞれのオーケストレーション可能なデバイスから受信したテレメトリに基づく、段階と、使用可能なリソースの説明に基づいて、オーケストレータからそれぞれのオーケストレーション可能なデバイスに定義されたオーケストレーションの階層を組織化する段階と、オーケストレーションの階層に基づいて、作業負荷をオーケストレーションエンジンからそれぞれのオーケストレーション可能なデバイスに分散する段階とを含む。
例３２では、例３１の主題は、階層がオーケストレーションの機能階層であり、階層がサブオーケストレーションソフトウェアモジュールの使用を通じてアプリケーションオーケストレーションを定義し、それぞれのサブオーケストレーションソフトウェアモジュールが、ネットワークオーケストレーション、仮想マシンオーケストレーション、タスクオーケストレーション、およびストレージオーケストレーション用のソフトウェアモジュールを含むことを含む。
例３３では、例３１〜３２の主題は、オーケストレーションの階層が単一レベルの階層であり、オーケストレーションエンジンがそれぞれのオーケストレーション可能なデバイスのサブセットを割り当てて、それぞれの作業負荷の一部を実行することを含む。
例３４では、例３１〜３３の主題は、オーケストレーションの階層は複数レベルの階層であり、複数レベルの階層は、複数レベルの階層の中間レベルにあるそれぞれの連携オーケストレーションエンジンを備えたサブオーケストレータを含み、オーケストレーションエンジンおよびオーケストレータは、複数レベルの階層のトップレベルで動作し、それぞれの連携オーケストレーションエンジンは、テレメトリのコレクションと、複数レベルの階層の最下位レベルにあるそれぞれのオーケストレーション可能なデバイス間の作業負荷の分散を連携するように動作することを含む。
例３５では、例３４の主題は、それぞれのオーケストレーション可能なデバイスのグループがそれぞれのクラスタに組織化され、それぞれのサブオーケストレータがテレメトリの収集およびそれぞれのクラスタにおける作業負荷の分散を連携することを含む。
例３６では、例３１〜３５の主題は、オーケストレーションの階層が複数レベルの階層であり、複数レベルの階層は、複数レベルの階層の中間レベルにあるマスターのオーケストレーション可能なデバイスと、複数レベルの階層の最下位レベルにあるスレーブノードとを含み、オーケストレーションエンジンおよびオーケストレータはマルチレベル階層のトップレベルで動作し、マスターのオーケストレーション可能なデバイスは、テレメトリの収集とスレーブノード間の作業負荷の分散を連携するそれぞれのエージェントを含むことを含む。
例３７では、例３６の主題は、それぞれのクラスタが、少なくとも１つのスレーブノードへのそれぞれのマスターのオーケストレーション可能なデバイスのペアリングに基づいて組織化され、それぞれのエージェントは、それぞれのクラスタ内の作業負荷の分散を連携することを含む。
例３８では、例３６〜３７の主題は、複数レベルの階層の最下位レベルでのそれぞれのスレーブノードの検出、発見、および配置を実行する段階を含む。
例３９では、例３１〜３８の主題は、組織化されたオーケストレーションのコンポーネントからソフトウェアデータ、ハードウェアデータ、およびネットワークデータを収集する段階であって、組織化されたオーケストレーションのコンポーネントは、レガシーコンポーネントとオーケストレーション可能なコンポーネントを含む、段階と、収集されたソフトウェアデータ、ハードウェアデータ、およびネットワークデータに基づいて、オーケストレーションサーバによる監視を実行する段階と、オーケストレーションサーバから組織化されたオーケストレーションのコンポーネントにフィードバックと制御を提供し、監視に応答して組織化されたオーケストレーションを制御する段階とを含む。
例４０では、例１〜３９の主題は、ソフトウェア定義型産業システム用の自己記述的制御アプリケーションおよびソフトウェアモジュールの定義と配置を含み、自己記述的制御アプリケーションは複数の自己記述的オーケストレーション可能なソフトウェアモジュールを含む。
例４１では、例４０の主題は、オーケストレーション可能なソフトウェアモジュールの特性を説明するモジュールマニフェストを作成する段階と、オーケストレーション可能なソフトウェアモジュール内で使用可能な機能の定義および接続に基づいてアプリケーション仕様を定義する段階と、オーケストレーション可能なソフトウェアモジュールのオペレーションのオプションと代替案を定義する段階と、オプションと代替案に基づいて、オーケストレーション可能なソフトウェアモジュールの選択を実行する段階とを含む。
例４２では、例４１の主題は、シュミレーションされたアプリケーション設定におけるオーケストレーション可能なソフトウェアモジュールのオペレーションをエミュレートし、評価する段階を含み、オーケストレーション可能なソフトウェアモジュールの選択は、シュミレーションされたアプリケーション設定の結果に基づく。
例４３では、例４２の主題は、オーケストレーション可能なソフトウェアモジュールのオペレーションをエミュレートおよび評価するオペレーションは、使用可能なアプリケーションおよびアプリケーション仕様と１つまたは複数のモジュールマニフェストを使用するソフトウェアモジュール構成を決定する段階と、特性化コントローラを介して複数のオーケストレーションシナリオを定義する段階と、複数のオーケストレーションシナリオを実現するために、アプリケーションモジュールと、オプションを定義した少なくとも１つの代替アプリケーションモジュールをシミュレーターで実行する段階と、ハードウェア性能とユーザ入力に基づいて、アプリケーションモジュールと少なくとも１つの代替アプリケーションモジュールの実行結果を評価する段階と、アプリケーションモジュールおよび少なくとも１つの代替アプリケーションモジュールの実行結果のそれぞれのスコアを生成する段階とを含む。
例４４では、例４２〜４３の主題は、実行結果に関連するシナリオが、それぞれのスコアに基づいてアプリケーションで使用するために自動的に組み込まれることを含む。
例４５では、例１の主題は、ＩＯコンバータなどでフィールドデバイス（例えば、センサ）からデータを受信する段階と、フィールドデバイスからのデータをフィールドデバイスバスプロトコルに従って変換する段階と、変換されたデータをフィールドデバイス抽象化バスに送信する段階と、フィールドデバイス抽象化バスを介して制御デバイスから制御信号を受信する段階と、制御信号に基づいてフィールドデバイスに電気信号を送信する段階とを含む。
例４６では、例１の主題は、センサバスなどの複数の対応するＩＯコンバータを介して複数のフィールドデバイス（例えば、センサ）からデータを受信する段階と、１つまたは複数の制御機能にデータを送信する段階と、データに基づいて１つまたは複数の制御機能から１つまたは複数の制御信号を受信する段階と、１つまたは複数の制御信号を複数のＩＯコンバータのそれぞれのＩＯコンバータに送信する段階とを含む。
例４７では、例４６の主題は、ＩＯコンバータモードコントローラから情報を受信する段階と、ＩＯコンバータモードコントローラから受信した情報に従ってフィールドデバイスへのＩＯコンバータの割り当てを容易にする段階とを含む。
例４８では、例１の主題は、産業制御システムの複数のアラームに関する情報を保存する段階と、情報からの複数のアラームのデータ、コンテキスト、またはアラーム構成を分析する段階と、情報からのアラームストリームの類似性を決定する段階と、２つまたはそれより多くのアラームでアラームイベントを検出する段階と、２つまたはそれより多くのアラームが発行されないようにする段階と、発行されないようにした２つまたはそれより多くのアラームに対してクラスタ化されたアラームを生成する段階とを含む。
例４９では、例４８の主題は、複数のアラームのうちの１つまたは複数に対する変更を推奨する段階と、または新しいアラームを推奨する段階とを含む。
例５０では、例１の主題は、新しい閉ループ作業負荷アルゴリズムの自動作成を管理する段階を含む。
例５１では、例５０の主題は、現在のプロセス（例えば、産業制御システムプロセス）に対する新しいアルゴリズムの品質または感度の評価を実行する段階を含む。
例５２では、例５０〜５１の主題は、動作制約境界を自動的に確立する段階を含む。
例５３では、例５０〜５２の主題は、既存のプロセスに対する新しいアルゴリズムの安全性を自動的に評価する段階を含む。
例５４では、例５０〜５３の主題は、より広範なプロセスの価値を自動的に評価する段階を含む。
例５５では、例５０〜５４の主題は、制御環境での配置の実現可能性についてシステムを自動的に評価する段階を含む。
例５６では、例５０〜５５の主題は、新しいアプリケーション制御戦略を物理的に配置または監視する段階を含む。
例５７では、例５０〜５６の主題は、新しいアルゴリズムをライフサイクル管理システムに統合する段階を含む。
例５８では、例５０〜５７の主題は、新しいアルゴリズムをサポート終了処理に統合する段階を含む。
例５９では、例５０〜５８の主題は、例５１〜５８を順番に実行する段階を含む。
例６０では、例１の主題は、オーケストレーションサーバなどの産業制御システム（例えば、リング配置）のエッジ制御ノードの計算要件を決定する段階と、１つまたは複数のエッジ制御ノードのＣＰＵを起動する指示を受信する段階と、起動するＣＰＵを備えたエッジ制御ノードに認証済み起動コードを送信する段階とを含む。
例６１では、例１の主題は、エッジ制御ノードで認証済み起動コードを受信する段階と、エッジ制御ノードでコードを認証する段階と、マイクロプロセッサ（ＭＣＵ）を使用してエッジ制御ノードのＣＰＵを起動する段階と（例えば、低性能のプロセッサ）を含む。
例６２では、例６０〜６１の主題は、産業制御システムのオーケストレーションシステムによって配置されたエッジ制御ノードのリング配置で例６０〜６１を実行する段階を含む。
例６３では、例６１の主題は、エッジ制御ノードでオーケストレーションサーバから更新を受信してＣＰＵを停止するか、ＣＰＵを低電力状態にする段階を含む。
例６４は、コンピューティングシステムによって実行された場合にコンピューティングシステムに例１〜６３のいずれかを実行させる命令を含む少なくとも１つの機械可読媒体である。
例６５は、例１〜６３のいずれかを実行するためのそれぞれの手段を備える装置である。
例６６は、ソフトウェア定義型産業システムであり、それぞれのデバイスおよびそれぞれのデバイス内のそれぞれの回路を含み、それぞれの回路は、例１〜６３のいずれかのオペレーションを実行するように構成されている。
例６７は、例１〜６３のいずれかのオペレーションを実行するように構成された回路を含む装置である。
例６８では、例６７の主題は、装置が、適合された複数のフィールドデバイス、他のデバイスネットワーク、または他のネットワーク配置への接続を可能にするゲートウェイであることを含む。
例６９では、例６７〜６８の主題は、装置が、少なくとも１つのセンサおよび少なくとも１つのアクチュエータに動作可能に結合されたデバイスであることを含む。
例７０では、例６７〜６９の主題は、装置が複数のフィールドデバイスへの接続に適合されたエッジ制御ノード装置であることを含む。
例７１では、例６７〜７０の主題は、装置が複数のフィールドデバイスへの接続に適合されたインテリジェントＩ／Ｏコントローラデバイスであることを含む。
例７２では、例６７〜７１の主題は、装置が複数のフィールドデバイスへの接続に適合されたベーシックＩ／Ｏコントローラデバイスであることを含む。
例７３では、例６７〜７２の主題は、装置が、複数のネットワーク化されたシステムへの接続に適合された制御サーバコンピューティングシステムであることを含む。
例７４では、例６７〜７３の主題は、装置が複数のネットワーク化されたシステムへの接続に適合された制御処理ノードコンピューティングシステムであることを含む。
例７５は、フォグまたはクラウドネットワークトポロジ内に接続されたそれぞれのデバイスを含むネットワーク化システムであり、それぞれのデバイスは、例１〜６３のいずれかのオペレーションを実行するように構成された回路を含む。
例７６では、例７５の主題は、それぞれのデバイスがリアルタイムサービスバスを介して接続されることを含む。
例７７では、例７５〜７６の主題は、ネットワークトポロジは、冗長な一対のホストを介したソフトウェア定義型産業システム用のコントローラ、ストレージ、および計算機能を含むことを含む。
例７８では、例７５〜７７の主題は、ネットワークトポロジは、個別の物理ホストを介したソフトウェア定義型産業システム用のコントローラ、ストレージ、および計算機能を含むことを含む。
例７９は、フィールドデバイスから信号を受信し、入力／出力（ＩＯ）データを生成するためのＩＯサブシステムと、システムオンチップとを備える産業制御システムのエッジ制御ノードであって、システムオンチップは、ネットワークに通信可能に結合されたネットワーキングコンポーネントと、ＩＯサブシステムからのＩＯデータを変換し、変換されたデータをネットワーキングコンポーネントによってネットワークを経由してオーケストレーションサーバに送信するマイクロコントローラ（ＭＣＵ）と、最初は停止状態にあり、ネットワーキングコンポーネントを経由してオーケストレーションサーバからエッジ制御ノードで起動信号が受信されるのに応答して、起動状態に変化する中央処理装置（ＣＰＵ）とを有する、エッジ制御ノードである。
例８０では、例７９の主題は、ＣＰＵの起動状態が低電力モードおよび高電力モードを含むことを含む。
例８１では、例７９〜８０の主題は、ＣＰＵはさらに、起動状態で一定期間後にオーケストレーションサーバから停止信号を受信し、それに応じて停止状態に戻るように構成されることを含む。
例８２では、例７９〜８１の主題は、エッジ制御ノードが産業制御システムにおける複数のエッジ制御ノードの１つであり、複数のエッジ制御ノードが、ＣＰＵが起動した後の停止ＣＰＵの少なくとも１つのエッジ制御ノードを含むことを含む。
例８３では、例７９〜８２の主題は、産業制御システムの制御戦略を満たすためにＣＰＵが起動する必要があるというオーケストレーションサーバによる決定に基づいて、ＣＰＵは起動することを含む。
例８４では、例７９〜８３の主題は、ネットワーキングコンポーネントが時間依存のネットワーキングイーサネットスイッチであることを含む。
例８５では、例７９〜８４の主題は、ネットワークは、ネットワークをオーケストレーションサーバに接続するブリッジデバイスを備えたリングトポロジを有することを含む。
例８６では、例７９〜８５の主題は、起動信号がＭＣＵから直接ＣＰＵで受信されることを含む。
例８７では、例７９〜８６の主題は、ＣＰＵはさらにオーケストレーションサーバから処理命令を受信し、ＣＰＵは起動状態の場合に処理命令を実行することを含む。
例８８は、命令を含む少なくとも１つの非一時的な機械可読媒体であり、これは、オーケストレーションサーバのプロセッサによって実行される場合、プロセッサに次のオペレーションを実行させる。入力／出力（ＩＯ）データを受信し、ＩＯデータは、オーケストレーションサーバをエッジ制御ノードに接続するブリッジを介して受信され、ＩＯデータは、エッジ制御ノードのマイクロコントローラ（ＭＣＵ）で、ＩＯサブシステムで生成されたデータからネットワーキングコンポーネントによって送信されたパケットに変換され、認証された起動コードをエッジ制御ノードに送信して、エッジ制御ノードの中央処理装置（ＣＰＵ）を起動し、ＣＰＵは、最初に停止状態に置かれ、処理命令をＣＰＵに送信して実行する。
例８９では、例８８の主題は、オペレーションがさらにプロセッサに、エッジ制御ノードを含む産業制御システム内のエッジ制御ノードの計算要件を決定させ、ＣＰＵの起動が産業制御システムの制御戦略を満たすというオーケストレーションサーバによる決定に基づいて、ＣＰＵが起動されることを含む。
例９０では、例８８〜８９の主題は、オペレーションはさらに、プロセッサに、産業制御システム内のエッジ制御ノードのＣＰＵを起動する指示を受信させることを含む。
例９１では、例８８〜９０の主題は、ＣＰＵが起動する前に、認証された起動コードがＭＣＵによって認証されることを含む。
例９２では、例８８〜９１の主題は、オペレーションはさらに、プロセッサに停止コードをオーケストレーションサーバからＣＰＵに送信させて、ＣＰＵを停止することを含む。
例９３では、例８８〜９２の主題は、エッジ制御ノードが、ブリッジデバイスがネットワークをオーケストレーションサーバに接続するリングトポロジネットワーク内のノードであることを含む。
例９４は、以下を含む産業制御システムであり、複数のエッジ制御ノードを含むリングネットワークと、オーケストレーションサーバと、オーケストレーションサーバをリングネットワークに接続するブリッジとであり、複数のエッジ制御ノードは、次のものを含む第１エッジ制御ノードを含み、次のものを含むシステムオンチップであり、入力／出力（ＩＯ）データをＩＯサブシステムから変換し、変換されたデータをネットワーキングコンポーネント経由でオーケストレーションサーバにブリッジ経由で送信するマイクロコントローラ（ＭＣＵ）と、初期の停止状態にあり、オーケストレーションサーバから起動信号を受信し、起動信号の受信に応答して起動状態に変化するプロセッサである。
例９５では、例９４の主題は、プロセッサがさらに、起動状態にある期間後にオーケストレーションサーバから停止信号を受信し、それに応答して停止状態に戻るように構成されることを含む。
例９６では、例９４〜９５の主題は、プロセッサを起動することが産業制御システムの制御戦略を満たすというオーケストレーションサーバによる決定に基づいてプロセッサが起動されることを含む。
例９７では、例９４〜９６の主題は、起動信号がＭＣＵから直接プロセッサで受信されることを含む。
例９８では、例９４〜９７の主題は、第１エッジ制御ノードのプロセッサが起動された後、複数のエッジ制御ノードが、第２プロセッサが停止状態のままである第２エッジノードを含むことを含む。
例９９では、例９４〜９８の主題が、オーケストレーションサーバは、実行のために処理命令をプロセッサに送信するようにさらに構成されることを含む。
例１００では、例９４〜９９の主題は、プロセッサが中央処理装置（ＣＰＵ）であることを含む。
例１０１は、処理回路によって実行された場合に、処理回路に例７９〜１００のいずれかのオペレーションを実行させる命令を含む、少なくとも１つの機械可読媒体である。
例１０２は、例７９〜１００のいずれかを実装する手段を備える装置である。
例１０３は、例７９〜１００のいずれかを実装するシステムである。
例１０４は、例７９〜１００のいずれかを実装する方法である。
例１０５は、使用可能な複数のソフトウェアモジュールの動作態様を識別することであって、使用可能な複数のソフトウェアモジュールは、制御システム環境で機能オペレーションを実行するように適合される、識別することと、モジュールマニフェストから動作特性を識別することであって、動作特性は、使用可能な複数のソフトウェアモジュールが制御システムアプリケーションを実行するための環境を定義する、識別することと、使用可能な複数のソフトウェアモジュールからの識別された動作態様およびモジュールマニフェストからの識別された動作特性に基づいて、使用可能な複数のソフトウェアモジュールの中からソフトウェアモジュールを選択することと、制御システム環境で選択されたソフトウェアモジュールを実行させることであって、制御システムアプリケーションのアプリケーション仕様に従って実行が行われる、実行させることと、を行うように適合された処理回路を備える、装置である。
例１０６では、例１０５の主題は、使用可能な複数のソフトウェアモジュールの動作態様が、通信インタフェース、開始パラメータ、プラットフォーム要件、依存性、配置要件、または署名のうちの１つまたは複数に関連することを含む。
例１０７では、例１０５〜１０６の主題は、処理回路はさらに、動作特性および選択されたソフトウェアモジュールに基づいて、制御システムアプリケーションのアプリケーション仕様を生成するように適合され、アプリケーション仕様は、選択されたソフトウェアモジュールの制御パラメータの値を定義することを含む。
例１０８では、例１０７の主題は、アプリケーション仕様が、選択されたソフトウェアモジュールから第２の選択されたソフトウェアモジュールへの接続を示すことを含む。
例１０９では、例１０５〜１０８の主題は、処理回路はさらに、少なくとも２つの異なるハードウェアアーキテクチャを使用して、選択されたソフトウェアモジュールの制御システム環境での実行を評価し、少なくとも２つの異なるハードウェアアーキテクチャで実行されたオペレーションの効率測定を実行するように適合されることを含む。
例１１０では、例１０５〜１０９の主題は、制御システムアプリケーションおよびそれぞれのソフトウェアモジュールが、グラフィカルユーザインタフェースで視覚表現として表示され、視覚表現は、制御システムアプリケーション内のソフトウェアモジュールの１つまたは複数の入力または出力の関係を確立するために使用され、ソフトウェアモジュールへの入力または出力は、センサ、アクチュエータ、またはコントローラのうちの１つまたは複数の使用を含むことを含む。
例１１１では、例１０５〜１１０の主題は、装置がオーケストレーションデバイスであり、オーケストレーションデバイスが、ソフトウェアモジュールを実行する制御システム環境内の複数の実行デバイスに動作可能に結合され、少なくとも１つの実行デバイスを介して選択されたソフトウェアモジュール実行は、制御システム環境内の１つまたは複数の制御デバイスの機能オペレーションを生じさせることを含む。
例１１２では、例１１１の主題は、処理回路が、選択されたソフトウェアモジュールの実行を制御システム環境内のオーケストレーション制御戦略と連携するようにさらに適合されることを含む。
例１１３では、例１０５〜１１２の主題は、処理回路はさらに、複数のソフトウェアモジュールを選択することであって、複数のソフトウェアモジュールは、ソフトウェアモジュールの選択を含む、選択することと、動作特性に従って複数のソフトウェアモジュールを相互に接続することとを行うように適合される、ことを含む。
例１１４は、以下を含む方法であり、使用可能なソフトウェアモジュールの動作態様を識別する段階であって、使用可能な複数のソフトウェアモジュールは、制御システム環境において機能オペレーションを実行するように適合される、段階と、モジュールマニフェストから動作特性を識別する段階であって、動作特性は、使用可能な複数のソフトウェアモジュールが制御システムアプリケーションを実行するための環境を定義する、段階と、使用可能な複数のソフトウェアモジュールの識別された動作態様およびモジュールマニフェストからの識別された動作特性に基づいて、使用可能な複数のソフトウェアモジュールの中からソフトウェアモジュールを選択する段階と、制御システム環境で選択されたソフトウェアモジュールを実行させる段階であって、制御システムアプリケーションのアプリケーション仕様に従って実行が行われる、段階と、を含む。
例１１５では、例１１４の主題は、使用可能な複数のソフトウェアモジュールの動作態様が、通信インタフェース、開始パラメータ、プラットフォーム要件、依存性、配置要件、または署名のうちの１つまたは複数に関連することを含む。
例１１６では、例１１４〜１１５の主題は、動作特性に基づいて制御システムアプリケーションおよび選択されたソフトウェアモジュールのアプリケーション仕様を生成する段階を含み、アプリケーション仕様は、選択されたソフトウェアモジュールの制御パラメータの値を定義し、アプリケーション仕様は、選択されたソフトウェアモジュールから第２の選択されたソフトウェアモジュールへの接続を示す。
例１１７では、例１１４〜１１６の主題は、少なくとも２つの異なるハードウェアアーキテクチャを使用して、選択されたソフトウェアモジュールの制御システム環境での実行を評価する段階と、少なくとも２つの異なるハードウェアアーキテクチャで実行されたオペレーションの効率測定を識別する段階とを含む。
例１１８では、例１１４〜１１７の主題は、制御システムアプリケーションおよびそれぞれのソフトウェアモジュールがグラフィカルユーザインタフェースの視覚表現として表示され、視覚表現は、制御システムアプリケーション内のソフトウェアモジュールの１つまたは複数の入力または出力の関係を確立するために使用され、ソフトウェアモジュールへの入力または出力は、センサ、アクチュエータ、またはコントローラのうちの１つまたは複数の使用を含むことを含む。
例１１９では、例１１４〜１１８の主題は、方法がオーケストレーションデバイスによって実行され、オーケストレーションデバイスが、ソフトウェアモジュールを実行する制御システム環境内の複数の実行デバイスに動作可能に結合され、少なくとも１つの実行デバイスを介して選択されたソフトウェアモジュールの実行は、制御システム環境における１つまたは複数の制御デバイスの機能オペレーションを生じさせることを含む。
例１２０では、例１１９の主題は、選択されたソフトウェアモジュールの実行を制御システム環境内のオーケストレーション制御戦略と連携する段階を含む。
例１２１では、例１１９〜１２０の主題は、制御システム環境で使用するための複数のソフトウェアモジュールを選択する段階を含み、複数のソフトウェアモジュールは、ソフトウェアモジュールの選択を含み、そして、動作特性に従って複数のソフトウェアモジュールを相互に接続する段階を含む。
例１２２は、命令を含む少なくとも１つの非一時的な機械可読記憶媒体であり、命令は、デバイスの処理回路によって実行される場合、処理回路にオペレーションを実行させ、使用可能な複数のソフトウェアモジュールの動作態様を識別する段階であって、使用可能な複数のソフトウェアモジュールは、制御システム環境で機能オペレーションを実行するように適合される、段階と、モジュールマニフェストから動作特性を識別する段階であって、動作特性は、使用可能な複数のソフトウェアモジュールが制御システムアプリケーションを実行するための環境を定義する、段階と、使用可能な複数のソフトウェアモジュールの識別された動作態様およびモジュールマニフェストから識別された動作特性に基づいて、使用可能な複数のソフトウェアモジュールの中からソフトウェアモジュールを選択する段階と、制御システム環境で選択されたソフトウェアモジュールを実行させる段階であって、制御システムアプリケーションのアプリケーション仕様に従って実行が行われる、段階とを含む。
例１２３では、例１２２の主題は、使用可能な複数のソフトウェアモジュールの動作態様が、通信インタフェース、開始パラメータ、プラットフォーム要件、依存性、配置要件、または署名のうちの１つまたは複数に関連することを含む。
例１２４では、例１２２〜１２３の主題は、動作特性に基づいて制御システムアプリケーションおよび選択されたソフトウェアモジュールのアプリケーション仕様を生成する段階をさらに含むオペレーションを含み、アプリケーション仕様は、選択されたソフトウェアモジュールの制御パラメータの値を定義し、アプリケーション仕様は、選択されたソフトウェアモジュールから第２の選択されたソフトウェアモジュールへの接続を示す。
例１２５では、例１２２〜１２４の主題は、少なくとも２つの異なるハードウェアアーキテクチャを使用して、選択されたソフトウェアモジュールの制御システム環境での実行を評価する段階と、少なくとも２つの異なるハードウェアアーキテクチャで実行されたオペレーションの効率測定を識別する段階とをさらに含むオペレーションを含む。
例１２６では、例１２２〜１２５の主題は、制御システムアプリケーションおよびそれぞれのソフトウェアモジュールがグラフィカルユーザインタフェースで視覚表現として表示され、視覚表現は、制御システムアプリケーション内のソフトウェアモジュールの１つまたは複数の入力または出力の関係を確立するために使用され、ソフトウェアモジュールへの入力または出力は、センサ、アクチュエータ、またはコントローラのうちの１つまたは複数の使用を含むことを含む。
例１２７では、例１２２〜１２６の主題は、オペレーションがオーケストレーションデバイスによって実行され、オーケストレーションデバイスは、ソフトウェアモジュールを実行する制御システム環境内の複数の実行デバイスに動作可能に結合され、少なくとも１つの実行デバイスを介して選択されたソフトウェアモジュールの実行は、制御システム環境における１つまたは複数の制御デバイスの機能オペレーションを生じさせることを含む。
例１２８では、例１２７の主題は、選択されたソフトウェアモジュールの実行を制御システム環境内のオーケストレーション制御戦略と連携する段階をさらに含むオペレーションを含む。
例１２９では、例１２７〜１２８の主題は、制御システム環境で使用するための複数のソフトウェアモジュールを選択する段階であって、複数のソフトウェアモジュールは、ソフトウェアモジュールの選択を含む、段階と、動作特性に従って複数のソフトウェアモジュールを相互に接続する段階をさらに含むオペレーションを含む。
例１３０は、処理回路によって実行された場合に、処理回路に例１０５〜１２９のいずれかを実装するオペレーションを実行させる命令を含む少なくとも１つの機械可読媒体である。
例１３１は、例１０５〜１２９のいずれかを実装する手段を備える装置である。
例１３２は、例１０５〜１２９のいずれかを実装するシステムである。
例１３３は、例１０５〜１２９のいずれかを実装する方法である。
例１３４は、アプリケーションを実行する分散型ノードのオーケストレーションシステムであり、オーケストレーションシステムは、第１出力を有する第１モジュールを実行する第１ノードと、第２モジュールを実行する第２ノードであって、第２モジュールは第１出力を入力として使用し、第２出力を第３ノードで実行する第３モジュールに提供する、第２ノードと含み、第２ノードの故障の検出に応答して、第１ノードおよび第３ノードは、第２モジュールを再配置するための交換ノードを決定するために連携するように構成される。
例１３５では、例１３４の主題は、交換ノードが、第１出力を受信し、第２モジュールを動作させるように事前構成された冗長ノードであることを含む。
例１３６では、例１３５の主題は、冗長ノードが交換ノードとして動作するようになるまで、冗長ノードが出力を任意のノードに提供するために接続されないことを含む。
例１３７では、例１３５〜１３６の主題は、第２ノードは、第２モジュールに関するパラメータおよび状態情報を冗長ノードに定期的に送信するように構成されることを含む。
例１３８では、例１３５〜１３７の主題は、冗長ノードの故障に応答して、第２冗長ノードが交換ノードとして指定されることを含む。
例１３９では、例１３４〜１３８の主題は、第１ノードが、第１出力が生成される場合に第２モジュールの冗長状態を保存するように構成されることを含む。
例１４０では、例１３４〜１３９の主題は、連携する場合、第１ノードおよび第３ノードが、第２ノードに接続された一連のノードを決定するように構成されることを含む。
例１４１では、例１３４〜１４０の主題は、交換ノードを第１ノードに接続して第１モジュールから出力を受信し、第３ノードに接続して第２モジュールから第３モジュールに出力を提供するように構成されることを含む。
例１４２では、例１３４〜１４１の主題は、第１、第２、および第３ノード上の第１、第２、および第３モジュールの構成が最初にオーケストレーションサーバによって生成され、オーケストレーションサーバは、第１ノード、第２ノード、および第３ノードから切断されるように構成されることを含む。
例１４３では、例１３４〜１４２の主題は、第２ノードが仮想マシン上で実装され、第２モジュールが仮想マシン上の第２ノードのイメージに基づいて交換ノードでインスタンス化されることを含む。
例１４４では、例１３４〜１４３の主題は、第１ノードがリーダー選出アルゴリズムを使用してリーダーノードとして選択されることを含む。
例１４５は、オーケストレーションシステムの分散型ノードを使用してアプリケーションを実行する方法であり、この方法は、第１ノード上で第１モジュールを実行する段階であって、第１モジュールは第１出力を有する段階と、第２ノードで第２モジュールを実行する段階であって、第２モジュールは第１出力を入力として使用する段階と、第２モジュールからの第２出力を、第３ノードで実行される第３モジュールに提供すること段階と、第２ノードの故障の検出に応答して、第１ノードと第３ノードとの間で連携することにより、第２モジュールを再配置するための交換ノードを決定する段階とを含む。
例１４６では、例１４５の主題は、交換ノードを決定する段階が、第１出力を受信し、第２モジュールを動作するように事前構成された冗長ノードを識別する段階を含むことを含む。
例１４７では、例１４６の主題は、冗長ノードが交換ノードとして動作するようになるまで、冗長ノードが出力を任意のノードに提供するために接続されないことを含む。
例１４８では、例１４６〜１４７の主題は、第２ノードから冗長ノードに第２モジュールに関するパラメータと状態情報を定期的に送信する段階を含む。
例１４９では、例１４６〜１４８の主題は、冗長ノードの故障に応答して、第２冗長ノードを交換ノードとして指定する段階を含む。
例１５０では、例１４５〜１４９の主題は、第１ノードで、第１出力が生成された場合に第２モジュールの冗長状態を保存する段階を含む。
例１５１では、例１４５〜１５０の主題は、交換ノードを決定する段階が、第２ノードに接続された一連のノードを決定する段階を含むことを含む。
例１５２では、例１４９〜１５１の主題は、交換ノードを第１ノードに接続して第１モジュールから出力を受信する段階と、交換ノードを第３ノードに接続して第２モジュールから第３モジュールに出力を提供する段階とを含む。
例１５３では、例１４５〜１５２の主題は、最初にオーケストレーションサーバを使用して第１、第２、および第３ノード上の第１、第２、および第３モジュールの構成を生成する段階を含み、第２ノードが故障する前に、オーケストレーションサーバを第１ノード、第２ノード、および第３ノードから切断する段階をさらに含む。
例１５４では、例１４５〜１５３の主題は、仮想マシンに第２ノードを実装する段階を含み、仮想マシン上の第２ノードのイメージに基づいて、交換ノードに第２モジュールをインスタンス化する段階をさらに含む。
例１５５では、例１４５〜１５４の主題は、リーダー選出アルゴリズムを使用して第１ノードをリーダーノードとして選択する段階を含む。
例１５６は、処理回路によって実行された場合に、処理回路に例１３４〜１５５のいずれかを実装するオペレーションを実行させる命令を含む少なくとも１つの機械可読媒体である。
例１５７は、例１３４〜１５５のいずれかを実装するための手段を備える装置である。
例１５８は、例１３４〜１５５のいずれかを実装するシステムである。
例１５９は、例１３４〜１５５のいずれかを実装する方法である。
Claims (30)
- フィールドデバイスから信号を受信し、入力／出力（ＩＯ）データを生成するためのＩＯサブシステムと、
システムオンチップと
を備える産業制御システムのエッジ制御ノードであって、
前記システムオンチップは、
ネットワークに通信可能に結合されたネットワーキングコンポーネントと、
前記ＩＯサブシステムからの前記ＩＯデータを変換し、前記変換されたデータを前記ネットワーキングコンポーネントによって前記ネットワークを経由してオーケストレーションサーバに送信するマイクロコントローラ（ＭＣＵ）と、
最初は停止状態にあり、前記ネットワーキングコンポーネントを経由して前記オーケストレーションサーバから前記エッジ制御ノードで起動信号が受信されるのに応答して、起動状態に変化する中央処理装置（ＣＰＵ）と
を有する、エッジ制御ノード。 - 前記ＣＰＵの前記起動状態は、低電力モードおよび高電力モードを含む、
請求項１に記載のエッジ制御ノード。 - 前記ＣＰＵはさらに、前記起動状態にある期間の後に前記オーケストレーションサーバから停止信号を受信し、それに応答して前記停止状態に戻るように構成される、
請求項１に記載のエッジ制御ノード。 - 前記エッジ制御ノードは、前記産業制御システムにおける複数のエッジ制御ノードの１つであり、前記複数のエッジ制御ノードは、前記ＣＰＵが起動した後に停止ＣＰＵを有する少なくとも１つのエッジ制御ノードを含む、
請求項１に記載のエッジ制御ノード。 - 前記産業制御システムの制御戦略を満たすために前記ＣＰＵが起動する必要があるという前記オーケストレーションサーバによる決定に基づいて、前記ＣＰＵは起動する、
請求項１に記載のエッジ制御ノード。 - 前記ネットワーキングコンポーネントは、時間依存のネットワーキングイーサネットスイッチである、
請求項１に記載のエッジ制御ノード。 - 前記ネットワークは、ブリッジデバイスが前記ネットワークを前記オーケストレーションサーバに接続するリングトポロジを有する、
請求項１に記載のエッジ制御ノード。 - 前記ＣＰＵは、さらに、前記オーケストレーションサーバから処理命令を受信し、前記ＣＰＵは、前記起動状態にある場合に前記処理命令を実行する、
請求項１に記載のエッジ制御ノード。 - 請求項１〜８のいずれかに記載のオペレーションを実行する方法。
- 機械によって実行された場合に、前記機械に請求項１〜８のいずれかに記載のオペレーションを実行させるコンピューティングシステムのオペレーション命令を含む、
少なくとも１つの機械可読媒体。 - 使用可能な複数のソフトウェアモジュールの動作態様を識別することであって、前記使用可能な複数のソフトウェアモジュールは、制御システム環境で機能オペレーションを実行するように適合される、識別することと、
モジュールマニフェストから動作特性を識別することであって、前記動作特性は、前記使用可能な複数のソフトウェアモジュールが制御システムアプリケーションを実行するための環境を定義する、識別することと、
前記使用可能な複数のソフトウェアモジュールの前記識別された動作態様および前記モジュールマニフェストからの前記識別された動作特性に基づいて、前記使用可能な複数のソフトウェアモジュールの中からソフトウェアモジュールを選択することと、
前記制御システム環境で前記選択されたソフトウェアモジュールを実行させることであって、前記制御システムアプリケーションのアプリケーション仕様に従って前記実行が行われる、実行させることと、
を行うように適合された処理回路を備える、装置。 - 前記使用可能な複数のソフトウェアモジュールの前記動作態様は、通信インタフェース、開始パラメータ、プラットフォーム要件、依存性、配置要件、または署名のうちの１つまたは複数に関連する、
請求項１１に記載の装置。 - 前記処理回路は、さらに、
前記動作特性および前記選択されたソフトウェアモジュールに基づいて、前記制御システムアプリケーションの前記アプリケーション仕様を生成するように適合され、
前記アプリケーション仕様は、前記選択されたソフトウェアモジュールの制御パラメータの値を定義する、
請求項１１に記載の装置。 - 前記アプリケーション仕様は、前記選択されたソフトウェアモジュールから第２の選択されたソフトウェアモジュールへの接続を示す、
請求項１３に記載の装置。 - 前記処理回路はさらに、
少なくとも２つの異なるハードウェアアーキテクチャを使用して、前記選択されたソフトウェアモジュールの前記制御システム環境での前記実行を評価し、
前記少なくとも２つの異なるハードウェアアーキテクチャで実行されたオペレーションの効率測定を実行するように適合される、
請求項１１に記載の装置。 - 前記制御システムアプリケーションおよびそれぞれのソフトウェアモジュールは、グラフィカルユーザインタフェースにおいて視覚表現として表示され、前記視覚表現は、前記制御システムアプリケーション内の前記ソフトウェアモジュールの１つまたは複数の入力または出力の関係を確立するために使用され、前記ソフトウェアモジュールへの前記入力または出力は、センサ、アクチュエータ、またはコントローラのうちの１つまたは複数の使用を含む、
請求項１１に記載の装置。 - 前記装置はオーケストレーションデバイスであり、前記オーケストレーションデバイスは、ソフトウェアモジュールを実行する前記制御システム環境内の複数の実行デバイスに動作可能に結合され、少なくとも１つの実行デバイスを介した前記選択されたソフトウェアモジュールの前記実行は、前記制御システム環境内の１つまたは複数の制御デバイスの機能オペレーションを生じさせる、
請求項１１に記載の装置。 - 前記処理回路はさらに、
複数のソフトウェアモジュールを選択することであって、前記複数のソフトウェアモジュールは、前記ソフトウェアモジュールの選択を含む、選択することと、
前記動作特性に従って前記複数のソフトウェアモジュールを相互に接続することと
を行うように適合される、
請求項１１に記載の装置。 - 請求項１１〜１８のいずれかに記載のオペレーションを実行する方法。
- 機械によって実行された場合に、前記機械に請求項１１〜１８のいずれかに記載のオペレーションを実行させる、コンピューティングシステムのオペレーション命令を含む少なくとも１つの機械可読媒体。
- アプリケーションを実行する分散型ノードのオーケストレーションシステムであって、前記オーケストレーションシステムは、
第１出力を有する第１モジュールを実行する第１ノードと、
第２モジュールを実行する第２ノードであって、前記第２モジュールは前記第１出力を入力として使用し、第２出力を第３ノードで実行する第３モジュールに提供する、第２ノードと
を備え、
前記第２ノードの故障の検出に応答して、前記第１ノードおよび前記第３ノードは、前記第２モジュールを再配置するための交換ノードを決定するために連携するように構成される、
オーケストレーションシステム。 - 前記交換ノードは、前記第１出力を受信し、前記第２モジュールを動作するようになるまで、事前構成された冗長ノードである、
請求項２１に記載のオーケストレーションシステム。 - 前記冗長ノードは、前記冗長ノードが前記交換ノードとして動作するようになるまで、任意のノードに出力を提供するように接続されない、
請求項２２に記載のオーケストレーションシステム。 - 前記第２ノードは、前記第２モジュールに関するパラメータおよび状態情報を前記冗長ノードに定期的に送信するように構成される、
請求項２２に記載のオーケストレーションシステム。 - 前記冗長ノードの故障に応答して、第２冗長ノードは、前記交換ノードとして指定される、
請求項２２に記載のオーケストレーションシステム。 - 前記第１ノードは、前記第１出力が生成される場合に前記第２モジュールの冗長状態を保存するように構成される、
請求項２１に記載のオーケストレーションシステム。 - 前記第１ノードおよび前記第３ノードは、連携する場合、前記第２ノードに接続された一連のノードを決定するように構成される、
請求項２１に記載のオーケストレーションシステム。 - 前記第２ノードは仮想マシン上に実装され、前記第２モジュールは、前記仮想マシン上の前記第２ノードのイメージに基づいて前記交換ノードでインスタンス化される、
請求項２１に記載のオーケストレーションシステム。 - 請求項２１〜２８のいずれかに記載のオペレーションを実行する方法。
- 機械によって実行された場合に、前記機械に請求項２１〜２８のいずれかに記載のオペレーションを実行させるコンピューティングシステムのオペレーション命令を含む少なくとも１つの機械可読媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2022175986A JP7392245B2 (ja) | 2017-11-16 | 2022-11-02 | オーケストレーションシステム、コンピュータプログラム、非一時的機械可読記憶媒体、および、方法 |
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201762587227P | 2017-11-16 | 2017-11-16 | |
| US62/587,227 | 2017-11-16 | ||
| US201762612092P | 2017-12-29 | 2017-12-29 | |
| US62/612,092 | 2017-12-29 | ||
| PCT/US2018/053607 WO2019099111A1 (en) | 2017-11-16 | 2018-09-28 | Distributed software-defined industrial systems |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2022175986A Division JP7392245B2 (ja) | 2017-11-16 | 2022-11-02 | オーケストレーションシステム、コンピュータプログラム、非一時的機械可読記憶媒体、および、方法 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2021503639A true JP2021503639A (ja) | 2021-02-12 |
| JP2021503639A5 JP2021503639A5 (ja) | 2021-11-04 |
| JP7171713B2 JP7171713B2 (ja) | 2022-11-15 |
Family
ID=64051668
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2020518672A Active JP7171713B2 (ja) | 2017-11-16 | 2018-09-28 | 分散型のソフトウェア定義型産業システム |
| JP2022175986A Active JP7392245B2 (ja) | 2017-11-16 | 2022-11-02 | オーケストレーションシステム、コンピュータプログラム、非一時的機械可読記憶媒体、および、方法 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2022175986A Active JP7392245B2 (ja) | 2017-11-16 | 2022-11-02 | オーケストレーションシステム、コンピュータプログラム、非一時的機械可読記憶媒体、および、方法 |
Country Status (6)
| Country | Link |
|---|---|
| US (7) | US10868895B2 (ja) |
| JP (2) | JP7171713B2 (ja) |
| KR (1) | KR20200088803A (ja) |
| CN (1) | CN111164952A (ja) |
| DE (1) | DE112018005879T5 (ja) |
| WO (1) | WO2019099111A1 (ja) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2022025254A (ja) * | 2020-07-29 | 2022-02-10 | 東芝三菱電機産業システム株式会社 | 分散制御システム |
| JP2022032955A (ja) * | 2020-08-11 | 2022-02-25 | 株式会社日立製作所 | プランニングノード |
| US11265402B2 (en) | 2017-11-16 | 2022-03-01 | Intel Corporation | Distributed dynamic architecture for error correction |
| WO2023090119A1 (ja) * | 2021-11-22 | 2023-05-25 | ソニーセミコンダクタソリューションズ株式会社 | 情報処理装置、情報処理方法、プログラム |
| JP2023121593A (ja) * | 2022-02-21 | 2023-08-31 | 横河電機株式会社 | 水処理システム、水処理方法および情報処理装置 |
| US12034827B2 (en) | 2023-07-26 | 2024-07-09 | Intel Corporation | Distributed software-defined industrial systems |
Families Citing this family (199)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8560493B2 (en) | 2003-10-01 | 2013-10-15 | Google Inc. | Determining and/or using end user local time information in an ad system |
| US20050251444A1 (en) | 2004-05-10 | 2005-11-10 | Hal Varian | Facilitating the serving of ads having different treatments and/or characteristics, such as text ads and image ads |
| US20070157228A1 (en) | 2005-12-30 | 2007-07-05 | Jason Bayer | Advertising with video ad creatives |
| US10555054B2 (en) * | 2016-04-12 | 2020-02-04 | Cisco Technology, Inc. | On-demand modular fog computing resources |
| FR3061620B1 (fr) * | 2016-12-29 | 2019-05-31 | Bull Sas | Reseau informatique d'infrastructures de ressources de calcul et procede d'affectation de ces ressources a des applications client |
| DE112018002293T5 (de) * | 2017-05-01 | 2020-02-27 | Fisher-Rosemount Systems, Inc. | Industrielles steuerungssystem mit offener architektur |
| CN110622076B (zh) * | 2017-05-12 | 2021-04-30 | 利乐拉瓦尔集团及财务有限公司 | 自动化框架和控制方法 |
| EP3451248A1 (en) * | 2017-09-02 | 2019-03-06 | Tata Consultancy Services Limited | Systems and methods for computing and evaluating internet of things (iot) readiness of a product |
| US11616781B2 (en) * | 2017-12-05 | 2023-03-28 | Goldilock Secure s.r.o. | Air gap-based network isolation device |
| EP3521948A1 (en) * | 2018-02-06 | 2019-08-07 | Tata Consultancy Services Limited | Systems and methods for auto-generating a control and monitoring solution for smart and robotics environments |
| US10887230B2 (en) * | 2018-02-27 | 2021-01-05 | Cisco Technology, Inc. | In-situ operations, administration, and management (IOAM) and network event correlation for internet of things (IOT) |
| JP2019149001A (ja) * | 2018-02-27 | 2019-09-05 | 富士ゼロックス株式会社 | 複製処理装置、複製処理システム及び複製処理プログラム |
| US10880194B2 (en) * | 2018-03-29 | 2020-12-29 | Wipro Limited | Method and system for performing intelligent orchestration within a hybrid cloud |
| EP3750054B1 (en) * | 2018-04-27 | 2023-08-16 | Hewlett-Packard Development Company, L.P. | Signals to i/o devices based on virtual computer messages |
| US11822946B2 (en) * | 2018-06-28 | 2023-11-21 | Cable Television Laboratories, Inc. | Systems and methods for secure network management of virtual network functions |
| CN112602339B (zh) * | 2018-07-03 | 2024-05-28 | 瑞典爱立信有限公司 | 用于处置定位信息的第一节点、通信装置以及由其执行的方法 |
| DE102018116823A1 (de) * | 2018-07-11 | 2020-01-16 | Samson Aktiengesellschaft | System zum Bestimmen eines Real-Prozessparameters wenigstens eines Real-Feldgeräts, Verfahren zum Bestimmen eines Real-Prozessparameters wenigstens eines Real-Feldgeräts, Real-Feldgerät sowie Real-Strömungsstrecke einer prozesstechnischen Anlage |
| CA3108301C (en) * | 2018-08-01 | 2021-09-07 | Centurylink Intellectual Property Llc | Machine learning for quality of experience optimization |
| EP3847548A4 (en) * | 2018-09-10 | 2022-06-01 | AVEVA Software, LLC | EDGE HMI MODULE SERVER SYSTEM AND PROCEDURES |
| CN110896356B (zh) * | 2018-09-12 | 2021-02-02 | 宁德时代新能源科技股份有限公司 | 电池管理系统及系统中的通信方法 |
| EP3629108B1 (de) * | 2018-09-28 | 2022-08-24 | Siemens Aktiengesellschaft | Projektierung eines automatisierungssystems |
| DE102018124184A1 (de) * | 2018-10-01 | 2020-04-02 | Endress+Hauser Process Solutions Ag | Verfahren zum Etablieren einer Netzwerkkommunikation mittels OPC UA |
| US10523673B1 (en) * | 2018-10-08 | 2019-12-31 | Quest Automated Services, LLC | Automation system controller |
| EP3654121B1 (de) * | 2018-11-14 | 2021-06-09 | Siemens Aktiengesellschaft | Redundantes automatisierungssystem mit mehreren prozessoreinheiten je hardwareeinheit |
| EP3657281B1 (en) * | 2018-11-26 | 2022-11-30 | ASML Netherlands B.V. | Control strategy evaluation tool for a semiconductor manufacturing process and its user interface |
| US20220046095A1 (en) * | 2018-11-27 | 2022-02-10 | Siemens Industry Software Inc. | Centralized management of containerized applications deployed on distributed gateways |
| US11340877B2 (en) * | 2018-12-19 | 2022-05-24 | Network Native, Inc. | System and method for holistic application development and deployment in a distributed heterogeneous computing environment |
| JP7130551B2 (ja) * | 2018-12-27 | 2022-09-05 | ルネサスエレクトロニクス株式会社 | 半導体装置、通信システムおよび通信システム制御方法 |
| CA3126601A1 (en) * | 2019-01-13 | 2020-07-16 | Strong Force Iot Portfolio 2016, Llc | Methods, systems, kits and apparatuses for monitoring and managing industrial settings |
| EP3690576B1 (en) * | 2019-01-30 | 2024-04-24 | Schneider Electric Industries SAS | Control device and method for controlling a redundant connection in a flat network |
| US11349709B2 (en) * | 2019-02-13 | 2022-05-31 | Walmart Apollo, Llc | System and method for onboarding IOT devices |
| JP7156082B2 (ja) * | 2019-02-20 | 2022-10-19 | 日本電信電話株式会社 | サービス配置選定方法およびサービス配置選定プログラム |
| US11561782B2 (en) * | 2019-02-28 | 2023-01-24 | Hewlett Packard Enterprise Development Lp | Upgrade recommendations |
| US11356537B2 (en) * | 2019-03-11 | 2022-06-07 | At&T Intellectual Property I, L.P. | Self-learning connected-device network |
| EP3712730A1 (de) * | 2019-03-19 | 2020-09-23 | Siemens Aktiengesellschaft | Orchestrierung modularer technischer anlagen |
| CA3172460A1 (en) * | 2019-03-26 | 2020-10-01 | Abdo SHABAH | System and method for enabling an execution of a plurality of tasks in a heterogeneous dynamic environment |
| US11468188B2 (en) * | 2019-04-15 | 2022-10-11 | SmartDeployAI LLC | Smart deployai data pipeline digital signing and encryption |
| US20220248238A1 (en) * | 2019-05-01 | 2022-08-04 | Northeastern University | Operating System for Software-Defined Cellular Networks |
| EP3748562A1 (en) | 2019-05-08 | 2020-12-09 | EXFO Solutions SAS | Timeline visualization & investigation systems and methods for time lasting events |
| CN113994647B (zh) * | 2019-06-07 | 2023-11-17 | 大金工业株式会社 | 设备控制系统、设备的控制方法 |
| GB2624788A (en) | 2019-06-10 | 2024-05-29 | Fisher Rosemount Systems Inc | Virtualized real-time I/O in process control systems |
| GB2625653A (en) | 2019-06-10 | 2024-06-26 | Fisher Rosemount Systems Inc | Automatic load balancing and performance leveling of virtual nodes running real-time control in process control systems |
| US11231701B2 (en) | 2019-06-10 | 2022-01-25 | Fisher-Rosemount Systems, Inc. | Publish/subscribe protocol for real-time process control |
| US11537112B2 (en) * | 2019-06-10 | 2022-12-27 | Fisher-Rosemount Systems, Inc. | Automatic load balancing and performance leveling of virtual nodes running real-time control in process control systems |
| GB2621485A (en) | 2019-06-10 | 2024-02-14 | Fisher Rosemount Systems Inc | Ease of node switchovers in process control systems |
| US11249464B2 (en) | 2019-06-10 | 2022-02-15 | Fisher-Rosemount Systems, Inc. | Industrial control system architecture for real-time simulation and process control |
| US11681278B2 (en) * | 2019-06-19 | 2023-06-20 | Honeywell International Inc. | High availability for container based control execution |
| US11635990B2 (en) | 2019-07-01 | 2023-04-25 | Nutanix, Inc. | Scalable centralized manager including examples of data pipeline deployment to an edge system |
| US10893116B1 (en) | 2019-07-03 | 2021-01-12 | Nutanix, Inc. | Apparatuses and methods for edge computing application deployment in an IoT system |
| US11501881B2 (en) | 2019-07-03 | 2022-11-15 | Nutanix, Inc. | Apparatus and method for deploying a mobile device as a data source in an IoT system |
| EP3761193A1 (en) * | 2019-07-04 | 2021-01-06 | Siemens Aktiengesellschaft | Safety analysis of technical systems comprising human objects |
| EP3764178A1 (de) * | 2019-07-08 | 2021-01-13 | Siemens Aktiengesellschaft | Verfahren zum integrieren einer maschine oder eines moduls, schnittstelle zur integration, computerprogramm und computerlesbares medium |
| US11526343B2 (en) * | 2019-07-11 | 2022-12-13 | Microchip Technology Incorporated | System for improved evaluation of semiconductor hardware and corresponding method |
| DE112020003655T5 (de) * | 2019-07-31 | 2022-06-15 | Hyundai Motor Company | Sdn-basiertes eindrigungsverhinderungsverfahren für fahrzeuginternenetzwerke und system zur verwendung davon |
| WO2021016981A1 (zh) * | 2019-08-01 | 2021-02-04 | 西门子股份公司 | 现场数据传输方法、装置、系统和计算机可读介质 |
| US20210034767A1 (en) * | 2019-08-01 | 2021-02-04 | Palantir Technologies Inc. | Systems and methods for conducting data extraction using dedicated data extraction devices |
| US11475255B2 (en) * | 2019-08-30 | 2022-10-18 | Kabushiki Kaisha Toshiba | Method for adaptive context length control for on-line edge learning |
| US11150886B2 (en) * | 2019-09-03 | 2021-10-19 | Microsoft Technology Licensing, Llc | Automatic probabilistic upgrade of tenant devices |
| CN110647580B (zh) * | 2019-09-05 | 2022-06-10 | 南京邮电大学 | 分布式容器集群镜像管理主节点、从节点、系统及方法 |
| US11734300B2 (en) * | 2019-09-19 | 2023-08-22 | International Business Machines Corporation | Archival of digital twin based on IoT sensor activity |
| US11635980B2 (en) * | 2019-09-20 | 2023-04-25 | Fisher-Rosemount Systems, Inc. | Modular process control system |
| JP6847382B1 (ja) * | 2019-09-23 | 2021-03-24 | 株式会社デンソークリエイト | 設計支援ツール |
| CN114342338B (zh) * | 2019-09-29 | 2023-11-03 | 西门子股份公司 | 基于物联网模型的虚拟物联网设备生成方法及装置 |
| JP7120199B2 (ja) * | 2019-10-08 | 2022-08-17 | 横河電機株式会社 | 通信処理装置、通信処理方法、およびプログラム |
| EP3805993A1 (en) * | 2019-10-10 | 2021-04-14 | Siemens Aktiengesellschaft | Generation of graph-structured representations of brownfield systems |
| CN110703679A (zh) * | 2019-10-14 | 2020-01-17 | 明阳智慧能源集团股份公司 | 一种风力发电机组工业控制器 |
| US11032163B2 (en) * | 2019-10-25 | 2021-06-08 | Verizon Patent And Licensing Inc. | Method and system for selection and orchestration of multi-access edge computing resources |
| EP3816800A1 (en) * | 2019-10-31 | 2021-05-05 | ABB Schweiz AG | Assignment of tasks between a plurality of devices |
| US11287808B2 (en) * | 2019-10-31 | 2022-03-29 | Honeywell International Inc. | Industrial process control and automation system having decoupled controllers |
| US10986036B1 (en) * | 2019-11-01 | 2021-04-20 | Hon Lin Technology Co., Ltd. | Method and apparatus for orchestrating resources in multi-access edge computing (MEC) network |
| DE102019129969A1 (de) * | 2019-11-06 | 2021-05-06 | Endress+Hauser SE+Co. KG | System zur Ressourcenverwaltung in einer Anlage der Automatisierungstechnik |
| US11153165B2 (en) | 2019-11-06 | 2021-10-19 | Dell Products L.P. | System and method for providing an intelligent ephemeral distributed service model for server group provisioning |
| US11159435B2 (en) * | 2019-11-07 | 2021-10-26 | Abb Schweiz Ag | Time-sensitive networking for industrial automation |
| EP4046099A1 (en) * | 2019-11-12 | 2022-08-24 | Bright Machines, Inc. | A software defined manufacturing/assembly system |
| US11368525B2 (en) | 2019-12-02 | 2022-06-21 | Red Hat, Inc. | Relaying network management tasks using a multi-service receptor network |
| US11095573B2 (en) * | 2019-12-06 | 2021-08-17 | Micro Focus Llc | Recommendation engine for resource tagging |
| CN110891093B (zh) * | 2019-12-09 | 2022-02-22 | 中国科学院计算机网络信息中心 | 一种时延敏感网络中边缘计算节点选择方法及系统 |
| US11809284B2 (en) * | 2019-12-17 | 2023-11-07 | Infosys Limited | System and method of cloning a multi-tiered application |
| US11163540B2 (en) * | 2019-12-20 | 2021-11-02 | Ansys, Inc. | Application program for extension and deployment of integrated and exportable cross platform digital twin model |
| US11061666B1 (en) | 2020-01-07 | 2021-07-13 | International Business Machines Corporation | Distributing computing tasks to individual computer systems |
| US20230013006A1 (en) * | 2020-01-14 | 2023-01-19 | Dubai Electricity & Water Authority | A system for monitoring and controlling a dynamic network |
| JP7403332B2 (ja) * | 2020-01-28 | 2023-12-22 | 本田技研工業株式会社 | 動作装置 |
| US11374819B2 (en) * | 2020-01-31 | 2022-06-28 | Wyze Labs, Inc. | Systems and methods for creating virtual devices |
| JP7132257B2 (ja) * | 2020-02-04 | 2022-09-06 | 株式会社日立製作所 | 制御システム |
| US20230340845A1 (en) * | 2020-02-07 | 2023-10-26 | Schlumberger Technology Corporation | Oilfield data processing using distributed devices |
| US11586853B2 (en) | 2020-02-17 | 2023-02-21 | Wipro Limited | System and method of validating multi-vendor Internet-of-Things (IoT) devices using reinforcement learning |
| JP7167072B2 (ja) | 2020-02-19 | 2022-11-08 | 株式会社安川電機 | 生産システム、通信方法、及びプログラム |
| US11418595B2 (en) * | 2020-03-11 | 2022-08-16 | Amdocs Development Limited | System, method, and computer program for internet of things (IoT) community services |
| US20230088049A1 (en) * | 2020-03-11 | 2023-03-23 | Peter C. Salmon | Densely packed electronic systems |
| IL273321A (en) | 2020-03-16 | 2021-09-30 | Otorio Ltd | A system and method for reducing risk in an operational network |
| US11233707B2 (en) * | 2020-03-27 | 2022-01-25 | Raytheon Bbn Technologies Corp. | Metadata-based information provenance |
| US11831657B2 (en) | 2020-03-27 | 2023-11-28 | Raytheon Bbn Technologies Corp. | Trust policies for a data provisioning layer |
| US11762742B2 (en) * | 2020-03-31 | 2023-09-19 | Honeywell International Inc. | Process control system with different hardware architecture controller backup |
| EP3893106A1 (de) * | 2020-04-09 | 2021-10-13 | Siemens Aktiengesellschaft | Laufzeitumgebung zur ausführung wenigstens einer anlagentechnischen applikation und kopplung mindestens einer anlagentechnischen komponente |
| US10771319B1 (en) * | 2020-04-15 | 2020-09-08 | Deke Guo | Robustness verification method and apparatus for distributed control plane in software-defined network |
| US11681598B2 (en) | 2020-04-16 | 2023-06-20 | Texas Instruments Incorporated | Method and apparatus to facilitate low latency fault mitigation, QoS management and debug of a processing pipeline |
| CN111314228B (zh) * | 2020-05-11 | 2020-08-11 | 之江实验室 | 一种支持时间敏感网络功能的plc控制系统 |
| US11201785B1 (en) * | 2020-05-26 | 2021-12-14 | Dell Products L.P. | Cluster deployment and management system |
| GB2586913B (en) * | 2020-06-05 | 2021-11-10 | Iotech Systems Ltd | Data processing |
| US11782410B2 (en) * | 2020-06-06 | 2023-10-10 | Honeywell International Inc. | Building management system with control logic distributed between a virtual controller and a smart edge controller |
| CN111638945B (zh) * | 2020-06-09 | 2023-04-28 | 中国电力工程顾问集团中南电力设计院有限公司 | 基于容器技术的分散控制系统 |
| DE102020207219A1 (de) * | 2020-06-09 | 2021-12-09 | Zf Friedrichshafen Ag | Steuersystem für ein Fahrzeug |
| US11449359B2 (en) | 2020-06-12 | 2022-09-20 | Optum Services (Ireland) Limited | Prioritized data object processing under processing time constraints |
| WO2021260970A1 (ja) * | 2020-06-26 | 2021-12-30 | ソニーグループ株式会社 | ネットワークの制御方法、および、データ処理システム |
| KR102211876B1 (ko) * | 2020-07-14 | 2021-02-03 | 강재종 | 기존 필드버스 기반 자동제어 시스템의 사물인터넷 연동 장치 및 방법 |
| EP4362425A3 (en) * | 2020-07-20 | 2024-06-12 | Abb Schweiz Ag | Sensor system |
| US11533217B2 (en) | 2020-07-31 | 2022-12-20 | Hewlett Packard Enterprise Development Lp | Systems and methods for predictive assurance |
| CN111683005B (zh) * | 2020-08-14 | 2020-11-27 | 北京翼辉信息技术有限公司 | 一种物联网智能网关设备及其构建方法 |
| CN111682973B (zh) * | 2020-08-17 | 2020-11-13 | 烽火通信科技股份有限公司 | 一种边缘云的编排方法及系统 |
| JP7153942B2 (ja) * | 2020-08-17 | 2022-10-17 | ラトナ株式会社 | 情報処理装置、方法、コンピュータプログラム、及び、記録媒体 |
| EP3961336B1 (en) * | 2020-08-31 | 2024-01-24 | Siemens Aktiengesellschaft | Controlling an operation of a technical system automatically |
| US20220076159A1 (en) * | 2020-09-10 | 2022-03-10 | National Technology & Engineering Solutions Of Sandia, Llc | Entity modification of models |
| US11474873B2 (en) * | 2020-09-22 | 2022-10-18 | Rockwell Automation Technologies, Inc. | Implementing serverless functions using container orchestration systems and operational technology devices |
| US11989084B2 (en) | 2020-09-23 | 2024-05-21 | Honeywell International Inc. | Self-healing process control system |
| EP3974921A1 (en) * | 2020-09-24 | 2022-03-30 | Siemens Aktiengesellschaft | Integrated development module and method for engineering automation systems in an industrial automation environment |
| WO2022072912A1 (en) * | 2020-10-04 | 2022-04-07 | Trackonomy Systems, Inc. | Method for fast replacement of wireless iot product and system thereof |
| US20220107845A1 (en) * | 2020-10-05 | 2022-04-07 | Cachengo, Inc. | Integrated edge cloud architecture |
| JP7496756B2 (ja) * | 2020-10-16 | 2024-06-07 | 株式会社日立製作所 | 制御システム及びその制御方法 |
| CN112256390B (zh) * | 2020-10-22 | 2023-08-29 | 海光信息技术股份有限公司 | 一种度量管理方法及相关设备 |
| US11754990B2 (en) * | 2020-10-29 | 2023-09-12 | Morphix, Inc. | Edge computing device with artificial intelligence model for emulating control logic of a programmable logic controller |
| JP7449841B2 (ja) * | 2020-11-02 | 2024-03-14 | 株式会社日立製作所 | 中継装置および中継方法 |
| US11874938B2 (en) | 2020-11-03 | 2024-01-16 | Honeywell International Inc. | Admittance mechanism |
| CN112333069B (zh) * | 2020-11-03 | 2022-05-13 | 四川航天系统工程研究所 | 总线虚拟化通信方法 |
| CN112243206A (zh) * | 2020-11-05 | 2021-01-19 | 燕山大学 | 一种面向工业现场的无线网络可视化配置系统及方法 |
| US11726764B2 (en) | 2020-11-11 | 2023-08-15 | Nutanix, Inc. | Upgrade systems for service domains |
| US11665221B2 (en) | 2020-11-13 | 2023-05-30 | Nutanix, Inc. | Common services model for multi-cloud platform |
| US11584546B2 (en) * | 2020-11-25 | 2023-02-21 | Honeywell International Inc. | Airport gate visual docking guidance system digital twin |
| US11418362B2 (en) * | 2020-11-25 | 2022-08-16 | Schneider Electric It Corporation | Systems and methods for group control using service data objects |
| EP4006668A1 (en) * | 2020-11-26 | 2022-06-01 | ABB Schweiz AG | Resource management for modular plants |
| CN112583898B (zh) * | 2020-11-30 | 2023-08-15 | 北京百度网讯科技有限公司 | 业务流程编排方法、装置、以及可读介质 |
| JP2022091301A (ja) * | 2020-12-09 | 2022-06-21 | オムロン株式会社 | 制御システムおよび制御方法 |
| CN112596955B (zh) * | 2020-12-28 | 2024-06-18 | 山西云时代研发创新中心有限公司 | 云计算中处理大规模系统突发事件的应急处理系统及方法 |
| CN112612709B (zh) * | 2020-12-28 | 2022-08-02 | 卡斯柯信号有限公司 | 一种用于铁路信号系统的软件架构安全分析实现方法 |
| CN114765558B (zh) | 2021-01-15 | 2024-04-09 | 台达电子工业股份有限公司 | 工业设备监控方法及工业设备监控系统 |
| US11720382B2 (en) * | 2021-01-20 | 2023-08-08 | Vmware, Inc. | Declarative VM management for a container orchestrator in a virtualized computing system |
| US11354473B1 (en) * | 2021-01-28 | 2022-06-07 | Argo AI, LLC | Method and system for designing a robotic system architecture with optimized system latency |
| US11463326B2 (en) * | 2021-02-24 | 2022-10-04 | Cisco Technology, Inc. | Lightweight ring manager with distributed policies |
| US11736585B2 (en) | 2021-02-26 | 2023-08-22 | Nutanix, Inc. | Generic proxy endpoints using protocol tunnels including life cycle management and examples for distributed cloud native services and applications |
| US11762681B2 (en) | 2021-03-02 | 2023-09-19 | Vmware, Inc. | Dynamic configuration of virtual objects |
| US12003385B2 (en) * | 2021-03-02 | 2024-06-04 | Cisco Technology, Inc. | Dynamic network routing based on application load |
| EP4053698A1 (en) * | 2021-03-05 | 2022-09-07 | Siemens Aktiengesellschaft | On-demand edge-network deployment by industrial equipment |
| US11750696B2 (en) * | 2021-03-22 | 2023-09-05 | Yokogawa Electric Corporation | Commissioning distributed control nodes |
| EP4064637A1 (de) * | 2021-03-24 | 2022-09-28 | Siemens Aktiengesellschaft | Verfahren und vorrichtung zur konfiguration einer applikation |
| US11336536B1 (en) * | 2021-03-31 | 2022-05-17 | Landis+Gyr Innovations, Inc. | Dynamic processing distribution for utility communication networks |
| CN112948097B (zh) * | 2021-04-15 | 2022-10-14 | 哈工大机器人（合肥）国际创新研究院 | 一种iec61499的功能块执行调度方法及装置 |
| US11720602B2 (en) | 2021-05-10 | 2023-08-08 | Bank Of America Corporation | Systems and methods providing streamlined data correlation in edge computing |
| US20220385552A1 (en) * | 2021-05-27 | 2022-12-01 | At&T Intellectual Property I, L.P. | Record and replay network traffic |
| US11924019B2 (en) * | 2021-05-31 | 2024-03-05 | Jio Platforms Limited | Alarm management module for internet-of-things (IoT) network |
| JP2024521582A (ja) | 2021-06-10 | 2024-06-03 | セイリオン インコーポレイテッド | 分散ワークロードを処理する方法及びシステム |
| CN117616731A (zh) * | 2021-06-11 | 2024-02-27 | Abb股份有限公司 | 时间敏感网络模拟器 |
| US20220397891A1 (en) * | 2021-06-11 | 2022-12-15 | Honeywell International Inc. | Coordinating a single program running on multiple host controllers |
| BR112023024504A2 (pt) * | 2021-06-14 | 2024-02-15 | Bayer Ag | Sistemas e métodos para fornecer um link de máquina virtual para controles de processo |
| US12007747B2 (en) | 2021-06-16 | 2024-06-11 | Fisher-Rosemount Systems, Inc. | Software defined process control system and methods for industrial process plants |
| US11789428B2 (en) | 2021-06-16 | 2023-10-17 | Fisher-Rosemount Systems, Inc. | I/O server services for selecting and utilizing active controller outputs from containerized controller services in a process control environment |
| US20220404790A1 (en) * | 2021-06-16 | 2022-12-22 | Fisher-Rosemount Systems, Inc. | Visualization of a software defined process control system for industrial process plants |
| US11726933B2 (en) | 2021-06-16 | 2023-08-15 | Fisher-Rosemount Systems, Inc. | I/O server services configured to facilitate control in a process control environment by containerized controller services |
| US11960588B2 (en) | 2021-06-16 | 2024-04-16 | Fisher-Rosemount Systems, Inc | Security services in a software defined control system |
| US20220404789A1 (en) * | 2021-06-16 | 2022-12-22 | Fisher-Rosemount Systems, Inc. | Utilizing quality-of-service metrics to facilitate transitions between i/o channels for i/o server services |
| US20220404811A1 (en) * | 2021-06-16 | 2022-12-22 | Fisher-Rosemount Systems, Inc. | Systems and Methods for Dynamically Maintained Redundancy and Load Balancing in Software Defined Control Systems for Industrial Process Plants |
| US20220404799A1 (en) * | 2021-06-16 | 2022-12-22 | Fisher-Rosemount Systems, Inc. | Software defined process control system and methods for industrial process plants |
| US20220404810A1 (en) * | 2021-06-16 | 2022-12-22 | Fisher-Rosemount Systems, Inc. | Visualization of A software defined process control system for industrial process plants |
| US20220405116A1 (en) * | 2021-06-16 | 2022-12-22 | Fisher-Rosemount Systems, Inc. | Visualizsation of a software defined process control system for industrial process plants |
| CN113359645B (zh) * | 2021-06-30 | 2023-04-21 | 四川交达预应力工程检测科技有限公司 | 基于工程物联网的预应力施工监测预警系统及方法 |
| US12001874B2 (en) * | 2021-07-13 | 2024-06-04 | Rockwell Automation Technologies | Digital engineering secure remote access |
| US12020056B2 (en) | 2021-07-13 | 2024-06-25 | Rockwell Automation Technologies, Inc. | Industrial automation control project conversion |
| US11863560B2 (en) | 2021-07-15 | 2024-01-02 | Rockwell Automation Technologies, Inc. | Industrial automation secure remote access |
| CN114363187B (zh) * | 2021-07-16 | 2023-10-13 | 网络通信与安全紫金山实验室 | 一种虚拟工业设备节点的部署方法及系统 |
| US20230214283A1 (en) * | 2021-07-16 | 2023-07-06 | Cachengo, Inc. | Decentralized data centers |
| EP4134759A1 (en) * | 2021-08-09 | 2023-02-15 | Siemens Aktiengesellschaft | Computer-implemented method and orchestration system to orchestrate configurations of simulations based on digital twin models of modular plants |
| US20230052789A1 (en) * | 2021-08-12 | 2023-02-16 | Microsoft Technology Licensing, Llc | Isolating operating system environments in embedded devices |
| US11777821B2 (en) * | 2021-08-16 | 2023-10-03 | Verizon Patent And Licensing Inc. | Systems and methods for performance-aware controller node selection in high availability containerized environment |
| KR102404156B1 (ko) * | 2021-08-20 | 2022-05-31 | 국민대학교산학협력단 | 양자보안 통신장치 통합형 ｐｌｃ/ｈｍｉ 제어 시스템 및 방법 |
| CN113687636B (zh) * | 2021-08-23 | 2022-11-08 | 明度智云(浙江)科技有限公司 | 一种用于工业生产的设备管理方法、系统和存储介质 |
| CN113419504B (zh) * | 2021-08-24 | 2021-11-09 | 深圳市信润富联数字科技有限公司 | 超回松散工序的预热智能控制方法、系统及存储介质 |
| CN113721574B (zh) * | 2021-09-07 | 2023-07-18 | 中国联合网络通信集团有限公司 | 一种柔顺控制方法、mec、现场单元、柔顺控制系统及装置 |
| US20230075794A1 (en) * | 2021-09-07 | 2023-03-09 | Dish Wireless L.L.C. | System and method for data management in a distributed data mesh for 5g-wireless virtualized deployment |
| US20230142107A1 (en) * | 2021-11-05 | 2023-05-11 | Dragos, Inc. | Data pipeline management in operational technology hardware and networks |
| DE102021213022A1 (de) | 2021-11-19 | 2023-05-25 | Zf Friedrichshafen Ag | Steuervorrichtung für ein Fahrzeug und Verfahren zum Steuern eines Fahrzeugs |
| EP4198663A1 (de) * | 2021-12-16 | 2023-06-21 | Schneider Electric Industries SAS | Verfahren zum verteilten berechnen von berechnungsaufgaben |
| US11799721B2 (en) * | 2022-01-27 | 2023-10-24 | Vmware, Inc. | Document driven network configuration updater |
| US20230252831A1 (en) * | 2022-02-07 | 2023-08-10 | Rosemount Aerospace Inc. | Dynamic multi-stage air data probe prognostics health monitoring management |
| US20230254241A1 (en) * | 2022-02-07 | 2023-08-10 | Rosemount Aerospace Inc. | Dynamic air data probe prognostics health monitoring edge device |
| US20230284042A1 (en) * | 2022-03-07 | 2023-09-07 | Charter Communications Operating, Llc | Control of communication devices in a wireless network |
| CN115061718B (zh) * | 2022-03-24 | 2023-12-22 | 上海任意门科技有限公司 | 配置和运行状态机的方法、计算设备和计算机存储介质 |
| CN114844739A (zh) * | 2022-04-22 | 2022-08-02 | 道莅智远科技(青岛)有限公司 | 一种可实现工业总线实时性的方法 |
| US20240089181A1 (en) * | 2022-04-26 | 2024-03-14 | Motional Ad Llc | Software-defined compute nodes on multi-soc architectures |
| CN114756495B (zh) * | 2022-06-16 | 2022-09-06 | 中国人民解放军国防科技大学 | 基于分层消息软总线模型的操作系统及实现方法 |
| CN115114268B (zh) * | 2022-06-30 | 2023-08-11 | 北京亚控科技发展有限公司 | 一种组织未来状态孪生方法、装置及设备 |
| US11797388B1 (en) * | 2022-07-07 | 2023-10-24 | Bank Of America Corporation | Systems and methods for lossless network restoration and syncing |
| US11683377B1 (en) | 2022-07-22 | 2023-06-20 | Paypal, Inc. | Identification of redundant electronic modules in an interconnected network |
| US11818208B1 (en) | 2022-08-05 | 2023-11-14 | International Business Machines Corporation | Adaptive data protocol for IoT devices |
| DE102022120563A1 (de) * | 2022-08-16 | 2024-02-22 | Turck Holding Gmbh | MODULBUS-System und Verfahren zur Automation einer Behandlungsanlage |
| CN115499300B (zh) * | 2022-09-19 | 2024-03-15 | 八维通科技有限公司 | 嵌入式设备集群化运行架构系统、构建方法及构建装置 |
| EP4345708A1 (en) * | 2022-09-28 | 2024-04-03 | Abb Schweiz Ag | Method and system for automatic generation of a specification for an it topology of a control system |
| CN115580468A (zh) * | 2022-09-30 | 2023-01-06 | 中通服和信科技有限公司 | 基于sdp和边缘计算的工业互联网安全系统及方法 |
| EP4361866A1 (de) * | 2022-10-28 | 2024-05-01 | Siemens Aktiengesellschaft | Verfahren und system zur umgebungs-abhängigen sicherheitsbezogenen anomalieerkennung für eine containerinstanz |
| US11765240B1 (en) * | 2022-11-22 | 2023-09-19 | Bank Of America Corporation | Distributed publication/subscription as a service computing system |
| CN115794422B (zh) * | 2023-02-08 | 2023-06-13 | 中国电子科技集团公司第十研究所 | 一种测控基带处理池资源管控编排系统 |
| CN117499443B (zh) * | 2023-12-28 | 2024-03-29 | 湖南信健科技有限公司 | 一种分布式控制系统dcs通信松耦合管理系统 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07154506A (ja) * | 1993-11-29 | 1995-06-16 | Toshiba Corp | 通信システム |
| WO2016182656A1 (en) * | 2015-05-11 | 2016-11-17 | Intel Corporation | Technologies for secure bootstrapping of virtual network functions |
| JP2017046129A (ja) * | 2015-08-26 | 2017-03-02 | 株式会社日立製作所 | ネットワークノード、パス管理方法及び管理装置 |
| JP2017520937A (ja) * | 2014-05-29 | 2017-07-27 | アップル インコーポレイテッド | 常時オンプロセッサを有するシステムオンチップ |
Family Cites Families (40)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5341374A (en) * | 1991-03-01 | 1994-08-23 | Trilan Systems Corporation | Communication network integrating voice data and video with distributed call processing |
| JP3001410B2 (ja) | 1996-03-28 | 2000-01-24 | 日本電気テレコムシステム株式会社 | 自動迂回ルーティング方式 |
| US6999459B1 (en) | 1998-07-10 | 2006-02-14 | Pluris, Inc. | System and method for facilitating recovery from communication link failures in a digital data network |
| US7139925B2 (en) | 2002-04-29 | 2006-11-21 | Sun Microsystems, Inc. | System and method for dynamic cluster adjustment to node failures in a distributed data system |
| US7024483B2 (en) | 2002-04-29 | 2006-04-04 | Sun Microsystems, Inc. | System and method for topology manager employing finite state automata for dynamic cluster formation |
| US7206836B2 (en) | 2002-09-23 | 2007-04-17 | Sun Microsystems, Inc. | System and method for reforming a distributed data system cluster after temporary node failures or restarts |
| GB0426736D0 (en) | 2004-12-06 | 2005-01-12 | Omnifone Ltd | MyFone |
| UA91582C2 (ru) | 2005-12-26 | 2010-08-10 | Сейко Эпсон Корпорейшн | контейнер с материалом для печати и плата, устанавливаемая в контейнере с материалом для печати |
| US7852754B2 (en) * | 2006-03-17 | 2010-12-14 | Tellabs San Jose, Inc. | Method and apparatus for managing faults in a ring network |
| DE102006035526A1 (de) | 2006-07-27 | 2008-01-31 | Endress + Hauser Gmbh + Co. Kg | Verfahren zum Freischalten von Sonderfunktionalitäten bei Feldgeräten der Automatisierungstechnik |
| US9009327B2 (en) * | 2007-08-03 | 2015-04-14 | Citrix Systems, Inc. | Systems and methods for providing IIP address stickiness in an SSL VPN session failover environment |
| KR101508110B1 (ko) | 2008-01-22 | 2015-04-06 | 브룩스 오토메이션, 인크. | 크라이오 펌프 네트워크 |
| US20100208063A1 (en) * | 2009-02-19 | 2010-08-19 | Panasonic Corporation | System and methods for improving accuracy and robustness of abnormal behavior detection |
| US8055933B2 (en) | 2009-07-21 | 2011-11-08 | International Business Machines Corporation | Dynamic updating of failover policies for increased application availability |
| US8990397B2 (en) | 2009-07-31 | 2015-03-24 | Ntt Docomo, Inc. | Resource allocation protocol for a virtualized infrastructure with reliability guarantees |
| US20110289489A1 (en) | 2010-05-20 | 2011-11-24 | Verizon Patent And Licensing Inc. | Concurrent cross browser testing |
| JP5621668B2 (ja) | 2011-03-15 | 2014-11-12 | 富士通株式会社 | 伝送システム、冗長区間設定方法および接続ノード |
| US9026837B2 (en) | 2011-09-09 | 2015-05-05 | Microsoft Technology Licensing, Llc | Resource aware placement of applications in clusters |
| US9208007B2 (en) | 2012-01-18 | 2015-12-08 | International Business Machines Corporation | Open resilience framework for simplified and coordinated orchestration of multiple availability managers |
| US9041527B2 (en) | 2012-04-20 | 2015-05-26 | Numerex Corp. | System and method for using alarm system zones for remote objects |
| JP5949255B2 (ja) | 2012-07-18 | 2016-07-06 | 富士通株式会社 | 通信制御装置、及び通信制御方法 |
| US9774658B2 (en) | 2012-10-12 | 2017-09-26 | Citrix Systems, Inc. | Orchestration framework for connected devices |
| US9270596B2 (en) * | 2012-11-26 | 2016-02-23 | Verizon Patent And Licensing Inc. | Selection of virtual network elements |
| US9065810B2 (en) * | 2013-01-30 | 2015-06-23 | Ebay Inc. | Daisy chain distribution in data centers |
| US20140336984A1 (en) | 2013-05-13 | 2014-11-13 | Abb Technology Ag. | Conditional monitoring of industrial systems |
| US9348710B2 (en) | 2014-07-29 | 2016-05-24 | Saudi Arabian Oil Company | Proactive failure recovery model for distributed computing using a checkpoint frequency determined by a MTBF threshold |
| US20160065653A1 (en) | 2014-08-26 | 2016-03-03 | Fujitsu Limited | Internet of things (iot) device configuration construction |
| JP2016130962A (ja) | 2015-01-14 | 2016-07-21 | 富士通株式会社 | データ退避制御方法、データ退避制御プログラム、及びデータ退避制御装置 |
| US10387794B2 (en) * | 2015-01-22 | 2019-08-20 | Preferred Networks, Inc. | Machine learning with model filtering and model mixing for edge devices in a heterogeneous environment |
| US11042131B2 (en) * | 2015-03-16 | 2021-06-22 | Rockwell Automation Technologies, Inc. | Backup of an industrial automation plant in the cloud |
| US9961076B2 (en) * | 2015-05-11 | 2018-05-01 | Genesys Telecommunications Laboratoreis, Inc. | System and method for identity authentication |
| US10503484B2 (en) | 2015-06-08 | 2019-12-10 | Cisco Technology, Inc. | Virtual replication of physical things for scale-out in an internet of things integrated developer environment |
| US9871662B2 (en) | 2015-09-25 | 2018-01-16 | Netflix, Inc. | Systems and methods for digital certificate and encryption key management |
| US10140385B2 (en) * | 2015-10-14 | 2018-11-27 | Successfactors, Inc. | Configuring a presentation of data based on a context |
| US10339325B2 (en) * | 2016-03-03 | 2019-07-02 | JJD Software LLC | Multi-level security model for securing access to encrypted private data |
| US11250344B2 (en) * | 2016-07-07 | 2022-02-15 | Hcl Technologies Limited | Machine learning based analytics platform |
| US10469664B2 (en) | 2016-09-21 | 2019-11-05 | Genesys Telecommunications Laboratories, Inc. | System and method for managing multi-channel engagements |
| US10612999B2 (en) * | 2016-10-03 | 2020-04-07 | International Business Machines Corporation | Diagnostic fault detection using multivariate statistical pattern library |
| US11296902B2 (en) | 2017-02-05 | 2022-04-05 | Intel Corporation | Adaptive deployment of applications |
| WO2019099111A1 (en) | 2017-11-16 | 2019-05-23 | Intel Corporation | Distributed software-defined industrial systems |
-
2018
- 2018-09-28 WO PCT/US2018/053607 patent/WO2019099111A1/en active Application Filing
- 2018-09-28 US US16/147,168 patent/US10868895B2/en active Active
- 2018-09-28 KR KR1020207010940A patent/KR20200088803A/ko not_active Application Discontinuation
- 2018-09-28 CN CN201880063380.XA patent/CN111164952A/zh active Pending
- 2018-09-28 US US16/650,454 patent/US11330087B2/en active Active
- 2018-09-28 US US16/147,190 patent/US11637918B2/en active Active
- 2018-09-28 US US16/147,148 patent/US10739761B2/en active Active
- 2018-09-28 JP JP2020518672A patent/JP7171713B2/ja active Active
- 2018-09-28 DE DE112018005879.4T patent/DE112018005879T5/de active Pending
-
2020
- 2020-12-14 US US17/120,512 patent/US11265402B2/en active Active
-
2022
- 2022-02-23 US US17/679,003 patent/US11811903B2/en active Active
- 2022-05-09 US US17/739,684 patent/US11758031B2/en active Active
- 2022-11-02 JP JP2022175986A patent/JP7392245B2/ja active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH07154506A (ja) * | 1993-11-29 | 1995-06-16 | Toshiba Corp | 通信システム |
| JP2017520937A (ja) * | 2014-05-29 | 2017-07-27 | アップル インコーポレイテッド | 常時オンプロセッサを有するシステムオンチップ |
| WO2016182656A1 (en) * | 2015-05-11 | 2016-11-17 | Intel Corporation | Technologies for secure bootstrapping of virtual network functions |
| JP2017046129A (ja) * | 2015-08-26 | 2017-03-02 | 株式会社日立製作所 | ネットワークノード、パス管理方法及び管理装置 |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11265402B2 (en) | 2017-11-16 | 2022-03-01 | Intel Corporation | Distributed dynamic architecture for error correction |
| US11330087B2 (en) | 2017-11-16 | 2022-05-10 | Intel Corporation | Distributed software-defined industrial systems |
| US11758031B2 (en) | 2017-11-16 | 2023-09-12 | Intel Corporation | Distributed software-defined industrial systems |
| US11811903B2 (en) | 2017-11-16 | 2023-11-07 | Intel Corporation | Distributed dynamic architecture for error correction |
| JP2022025254A (ja) * | 2020-07-29 | 2022-02-10 | 東芝三菱電機産業システム株式会社 | 分散制御システム |
| JP7349416B2 (ja) | 2020-07-29 | 2023-09-22 | 東芝三菱電機産業システム株式会社 | 分散制御システム |
| JP2022032955A (ja) * | 2020-08-11 | 2022-02-25 | 株式会社日立製作所 | プランニングノード |
| JP7142747B2 (ja) | 2020-08-11 | 2022-09-27 | 株式会社日立製作所 | プランニングノード |
| WO2023090119A1 (ja) * | 2021-11-22 | 2023-05-25 | ソニーセミコンダクタソリューションズ株式会社 | 情報処理装置、情報処理方法、プログラム |
| JP2023121593A (ja) * | 2022-02-21 | 2023-08-31 | 横河電機株式会社 | 水処理システム、水処理方法および情報処理装置 |
| JP7444184B2 (ja) | 2022-02-21 | 2024-03-06 | 横河電機株式会社 | 水処理システム、水処理方法および情報処理装置 |
| US12034827B2 (en) | 2023-07-26 | 2024-07-09 | Intel Corporation | Distributed software-defined industrial systems |
Also Published As
| Publication number | Publication date |
|---|---|
| JP7171713B2 (ja) | 2022-11-15 |
| US11758031B2 (en) | 2023-09-12 |
| US20200310394A1 (en) | 2020-10-01 |
| WO2019099111A1 (en) | 2019-05-23 |
| US10739761B2 (en) | 2020-08-11 |
| US20220329676A1 (en) | 2022-10-13 |
| US20190041824A1 (en) | 2019-02-07 |
| DE112018005879T5 (de) | 2020-08-20 |
| US20220360653A1 (en) | 2022-11-10 |
| US20210243284A1 (en) | 2021-08-05 |
| JP2023024983A (ja) | 2023-02-21 |
| CN111164952A (zh) | 2020-05-15 |
| US20240064218A1 (en) | 2024-02-22 |
| US20190041830A1 (en) | 2019-02-07 |
| JP7392245B2 (ja) | 2023-12-06 |
| US11811903B2 (en) | 2023-11-07 |
| KR20200088803A (ko) | 2020-07-23 |
| US10868895B2 (en) | 2020-12-15 |
| US11265402B2 (en) | 2022-03-01 |
| US11637918B2 (en) | 2023-04-25 |
| US20190042378A1 (en) | 2019-02-07 |
| US11330087B2 (en) | 2022-05-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP7392245B2 (ja) | オーケストレーションシステム、コンピュータプログラム、非一時的機械可読記憶媒体、および、方法 | |
| EP4199450A1 (en) | Digital twin framework for next generation networks | |
| US20190097900A1 (en) | Zero-configuration cluster and provisioning pipeline for heterogeneous computing nodes | |
| Cao et al. | Edge computing: a primer | |
| WO2023091036A1 (en) | Systems and methods for autonomous monitoring in end-to-end orchestration | |
| Kertész et al. | An interoperable and self-adaptive approach for SLA-based service virtualization in heterogeneous Cloud environments | |
| Möstl et al. | Platform-centric self-awareness as a key enabler for controlling changes in CPS | |
| Church et al. | SCADA systems in the Cloud | |
| Feminella et al. | Piloteur: a lightweight platform for pilot studies of smart homes | |
| US20240019823A1 (en) | Process Control or Automation System Architecture | |
| US12034827B2 (en) | Distributed software-defined industrial systems | |
| Mehanovic et al. | Brume-a horizontally scalable and fault tolerant building operating system | |
| US20240232669A1 (en) | System to provide monte carlo as a service | |
| US20240134356A1 (en) | Compute Fabric Functionalities for a Process Control or Automation System | |
| US20240039870A1 (en) | Location specific communications gateway for multi-site enterprise | |
| US20240231334A9 (en) | Configuration support for a process control or automation system | |
| US20240235959A1 (en) | Systems and methods for autonomous monitoring in end-to-end orchestration | |
| US20240231335A9 (en) | Spoke and hub configuration for a process control or automation system | |
| Lalanda | Edge Computing and Learning | |
| Gómez Escobar | Design of a reference architecture for an IoT sensor network | |
| US20240022609A1 (en) | Security and resiliency for cloud to edge deployments | |
| Singh | Internet of things and neural network based energy optimization and predictive maintenance techniques in heterogeneous data centers | |
| Patera | Edge and Big Data technologies for Industry 4.0 to create an integrated pre-sale and after-sale environment | |
| Süß et al. | Compute and Virtualization | |
| WO2024086015A1 (en) | Nebula fleet management |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20210921 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20210921 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20220927 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20221004 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20221102 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 7171713 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |