

{"id":704,"date":"2013-01-22T17:44:59","date_gmt":"2013-01-22T16:44:59","guid":{"rendered":"https:\/\/project.inria.fr\/plasma-lab\/?page_id=704"},"modified":"2015-03-17T17:40:21","modified_gmt":"2015-03-17T16:40:21","slug":"system-of-systems","status":"publish","type":"page","link":"https:\/\/project.inria.fr\/plasma-lab\/examples\/system-of-systems\/","title":{"rendered":"Systems of Systems"},"content":{"rendered":"<p><div class=\"alert alert-success\" role=\"alert\"><p class=\"printonly\"><strong>Important!<\/strong><\/p><br \/>\nAll the technical details about the contract language are in <a href=\"http:\/\/hal.inria.fr\/hal-00778039\/PDF\/rreport.pdf\">this techinal report<\/a>. It gives all the details about the SMC process for Systems of Systems and the full specification of the Goal Specification Contract Language.<br \/>\n<\/div><\/p>\n<p style=\"text-align: justify;\">Recently, in <a title=\"Danse \" href=\"http:\/\/www.danse-ip.eu\/home\/\">DANSE<\/a> [<a href=\"https:\/\/project.inria.fr\/plasma-lab\/publications\/#ABL13\">ABL13<\/a>], we adapt the SMC techniques to treat large heterogeneous systems like Systems of Systems. Among them, one finds systems integrating multiple heterogeneous distributed applications communicating over a shared network. We proposed to extend <a href=\"http:\/\/www.omg.org\/\">UPDM<\/a> specification &#8211; the SoS specification &#8211; with some requirements that the SoS must satisfy. These requirements, are specified with the contract language we specially designed for the SoS\u2019s. This language is a combination of the <a href=\"http:\/\/www.omg.org\/\">Object Constraint Language<\/a> (OCL) and the contract patterns of the CSL \u00e0 la \u201d<a href=\"http:\/\/www.speeds.eu.com\/\">SPEEDS<\/a>\u201d. The SPEEDS contract specification patterns are used to give a high-level specification of real-time components. They have been introduced to enable the user to reason about event triggering that are equivalently replaced in DANSE by property satisfaction. The properties handled by these patterns are about the state of a SoS. We use OCL to specify these state properties. This language allows to build some behavioral properties to express some temporal relations about facts or events of the system denoted by the state properties. It is sufficiently powerful to describe precisely a state of a SoS. These requirements are viewed as behavioral objectives that support the SoS architect in assessing different strategies and finding the best ones. As shown in the following figure, these contracts are compiled into\u00a0B-LTL formulas that are verified against the SoS (whose constituent systems are compiled into <a href=\"http:\/\/www.omg.org\/\">FMI<\/a> executables) using Plasma-Lab combined with the efficient simulation engine DESYRE developed by <a title=\"Ales\" href=\"http:\/\/www.ales.eu.com\/site\/\">Ales<\/a>. The SMC tool-chain gives an estimation of the satisfiability of the contract by the SoS. The different results help the SoS architect to make good decisions about how to optimize the SoS strategies.<\/p>\n<div id=\"attachment_643\" style=\"width: 460px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/project.inria.fr\/plasma-lab\/files\/2013\/01\/DANSE.png\"><img loading=\"lazy\" decoding=\"async\" aria-describedby=\"caption-attachment-643\" class=\"size-large wp-image-643  \" title=\"SMC process in DANSE\" alt=\"SMC process in DANSE\" src=\"https:\/\/project.inria.fr\/plasma-lab\/files\/2013\/01\/DANSE-300x197.png\" width=\"450\" height=\"296\" srcset=\"https:\/\/project.inria.fr\/plasma-lab\/files\/2013\/01\/DANSE-300x197.png 300w, https:\/\/project.inria.fr\/plasma-lab\/files\/2013\/01\/DANSE-1024x675.png 1024w, https:\/\/project.inria.fr\/plasma-lab\/files\/2013\/01\/DANSE.png 1466w\" sizes=\"auto, (max-width: 450px) 100vw, 450px\" \/><\/a><p id=\"caption-attachment-643\" class=\"wp-caption-text\">Overview of the DANSE SMC process<\/p><\/div>\n<hr \/>\n<h3>Illustration using the CAE incubator<\/h3>\n<p style=\"text-align: justify;\">In the frame of the DANSE project, the Concept Alignment Example (CAE) is a fictive SoS example\u00a0inspired by real-world Emergency Response data to a city fire. It has been built as a playground to\u00a0demonstrate new methods and models for the analysis and visualization of SoS designs. All structural\u00a0modeling has been performed using UPDM views, and behaviors have been added on a subset of the\u00a0constituents that we called \u201dCAE incubator\u201d, using simple SysML constructs (modeled in state machines)\u00a0extended by a few stereotypes (e.g. for storing stochastic information).\u00a0Behavioral modeling in the CAE incubator is focused on following constituent systems: Fire HQ,\u00a0Fire Station, Fire Fighting Car and District. The city districts have been added as constituent systems\u00a0because they play an important role in the SoS: their behavior describes how the fires arise, expand and\u00a0spread to neighbor districts. In the frame of the CAE, all behaviors are abstracted in state machines using\u00a0<a title=\"IBM Rhapsody\" href=\"http:\/\/www-142.ibm.com\/software\/products\/us\/en\/ratirhapfami\/\">IBM Rhapsody<\/a>, but it would be possible to use any other language and tool as long as it is compliant\u00a0with the FMI export format.\u00a0The following figure shows the overall architecture of the CAE incubator as well as the behavior of\u00a0one of the constituent types: a fire fighting car.\u00a0We attached to the CAE incubator the following requirements, written accordingly to our proposed<br \/>\nformalism:<\/p>\n<table>\n<tbody>\n<tr>\n<td><em>\u201dAny district cannot have more than 1 fire station, except if all districts have at least 1\u201d<\/em><\/p>\n<p><em><\/em><strong><span style=\"color: #ff0000;\">SoS.itsDistricts<\/span><span style=\"color: #0000ff;\">\u2192exists(<\/span><\/strong>district | district.<strong><span style=\"color: #ff0000;\">containedFireStations<\/span><span style=\"color: #0000ff;\">\u2192size() &gt; 1) implies<\/span><\/strong><br \/>\n<strong><span style=\"color: #ff0000;\">SoS.itsDistricts<\/span><span style=\"color: #0000ff;\">\u2192forAll(<\/span><\/strong>district | district.<strong><span style=\"color: #ff0000;\">containedFireStations<\/span><span style=\"color: #0000ff;\">\u2192size() \u2265 1)<\/span><\/strong><\/td>\n<\/tr>\n<tr>\n<td><em>\u201dThe mean city area under fire shall be less than 0.01%\u201d<\/em><\/p>\n<p><em><\/em><strong>mean<span style=\"color: #ff0000;\"><span style=\"color: #000000;\">(<\/span>SoS.itsDistricts.fireArea<\/span><span style=\"color: #0000ff;\">\u2192sum()<\/span>)<\/strong>\u2264 0.0001<\/td>\n<\/tr>\n<tr>\n<td><em>\u201dThe fire fighting cars hosted by a fire station shall be used all simultaneously at least once<\/em>\u00a0<em>in 6 months\u201d<\/em><\/p>\n<p><em><\/em><strong><span style=\"color: #ff0000;\">SoS.itsFireStations<\/span><span style=\"color: #0000ff;\">\u2192forAll(<\/span><\/strong>fireStation |<br \/>\n<strong>Whenever [<\/strong>fireStation<strong>.<span style=\"color: #ff0000;\">hostedFireFightingCars<\/span><span style=\"color: #0000ff;\">\u2192exists(<\/span><\/strong>ffCar | ffCar.<span style=\"color: #ff0000;\"><strong>isAtFireStation<\/strong><\/span><span style=\"color: #0000ff;\">)<\/span><strong>] occurs,<\/strong><\/p>\n<p>[<strong><\/strong>fireStation.<strong><span style=\"color: #ff0000;\">hostedFireFightingCars<\/span><span style=\"color: #0000ff;\">\u2192forall(<\/span><\/strong>ffCar | ffCar.isAtFireStation <strong><span style=\"color: #0000ff;\">= false)<\/span>]\u00a0<\/strong><\/p>\n<p><strong>occurs within [6 months]<span style=\"color: #0000ff;\">)<\/span><\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p style=\"text-align: justify;\">The previous table illustrates the kind of properties that we express with a new contract language we developed for extending the SysML\/UPDM specifications of SoS.\u00a0We use syntactic coloring to distinguish the different parts of the language used in the property: the words in red are identifiers from the model, the blue part is from OCL and bold black keywords are temporal operators. These requirements show the capabilities of our language using different requirements of this use case. Whereas the requirement 1 is purely structural, the requirements 2 and 3 are relative to the execution of the SoS: the first one is written using strictly OCL, the second one shows the cumulative operators we introduced and the third one is defined with a behavioral pattern. The presented requirements are contracts without assumption or, more precisely, they are contracts with an assumption that is implicitly \u201dtrue\u201d.<br \/>\nAs described in [<a href=\"https:\/\/project.inria.fr\/plasma-lab\/publications\/#ABL13\">ABL13<\/a>],\u00a0these requirements are translated to the &#8220;lower-level B-LTL specification&#8221; used by Plasma-Lab.<br \/>\nEach behavioral pattern\u00a0is translated in a equivalent B-LTL scheme combined with the state propositions expressed in OCL. Thus, a formula can starts with quantification expressed with OCL.<br \/>\nThese quantification opertors are defined over the initial state of the SoS, and there are compiled in order to simplify the job of the B-LTL checker in Plasma-Lab. As example, we breifly present the translation of the requirement 3. In order to achieve this translation, we need the time bound \\(k = 6\\ months\\) that we expect for the SoS simulation. We obtain a formula<\/p>\n\\( \\displaystyle<br \/>\n\\phi = \\left\\{<br \/>\n\\begin{array}{c}<br \/>\nG_{\\le k &#8211; 6months}(\\Psi_1({\\tt fireStation_1}) \\implies F_{\\le 6months} \\Psi_2({\\tt fireStation_1}))\\\\<br \/>\n\\bigwedge\\\\<br \/>\nG_{\\le k &#8211; 6months}(\\Psi_1({\\tt fireStation_2}) \\implies F_{\\le 6months} \\Psi_2({\\tt fireStation_2}))\\\\<br \/>\n\\bigwedge\\\\<br \/>\nG_{\\le k &#8211; 6months}(\\Psi_1({\\tt fireStation_3}) \\implies F_{\\le 6months} \\Psi_2({\\tt fireStation_3}))\\\\<br \/>\n\\end{array}\\right.<br \/>\n\\)\n<p style=\"text-align: justify;\">where \\(\\Psi_1({\\tt fireStation_i})\\) and \\(\\Psi_2({\\tt fireStation_i})\\) correspond to the OCL expressions in brackets, e.g. \\({\\tt fireStation.hostedFireFightingCars\\rightarrow exists(isAtFireStation)}\\) and \\({\\tt fireStation.hosted-}\\) \\({\\tt FireFightingCars\\rightarrow forall(isAtFireStation = false)}\\). For the OCL quantification operators, we unfold the OCL quantifications that occur in \\(\\Psi_1\\) and \\(\\Psi_2\\). The next table gives the result of this unfolding in \\(\\Psi_1({\\tt fireStation_i})\\) and \\(\\Psi_2({\\tt fireStation_i})\\) for each \\({\\tt fireStation}\\). Finally, replacing all occurences of \\(\\Psi_1({\\tt fireStation_i})\\) and \\(\\Psi_2({\\tt fireStation_i})\\) in \\(\\phi\\) gives the complete translation in B-LTL.<\/p>\n<p>&nbsp;<\/p>\n<table>\n<tbody>\n<tr>\n<th>Componenent<\/th>\n<th>\\(\\Psi_1\\)<\/th>\n<th>\\(\\Psi_2\\)<\/th>\n<td>\\({\\tt fireStation_2}\\)<\/td>\n<td>\u00a0\\(\\displaystyle \\begin{array}{l}<br \/>\n{\\tt fireFightingCar1.isAtFireStation}\\ \\lor\\\\ {\\tt fireFightingCar2.isAtFireStation}\\ \\lor\\\\ {\\tt fireFightingCar3.isAtFireStation} \\end{array}\\)<\/td>\n<td>\\(\\displaystyle\\begin{array}{l}<br \/>\n\\neg {\\tt fireFightingCar1.isAtFireStation}\\ \\land\\\\ \\neg {\\tt fireFightingCar2.isAtFireStation}\\ \\land\\\\ \\neg {\\tt fireFightingCar3.isAtFireStation}<br \/>\n\\end{array} \\)<\/td>\n<td>\\({\\tt fireStation_2}\\)<\/td>\n<td>\\(\\displaystyle\\begin{array}{l}<br \/>\n{\\tt fireFightingCar4.isAtFireStation}\\ \\lor\\\\ {\\tt fireFightingCar5.isAtFireStation}<br \/>\n\\end{array}\\)<\/td>\n<td>\\(\\displaystyle\\begin{array}{l}<br \/>\n\\neg {\\tt fireFightingCar4.isAtFireStation}\\ \\land\\\\ \\neg {\\tt fireFightingCar5.isAtFireStation}<br \/>\n\\end{array} \\)<\/td>\n<td>\\({\\tt fireStation_3}\\)<\/td>\n<td>\\(\\displaystyle\\begin{array}{l}<br \/>\n{\\tt fireFightingCar6.isAtFireStation}\\ \\lor\\\\ {\\tt fireFightingCar7.isAtFireStation}<br \/>\n\\end{array} \\)<\/td>\n<td>\\(\\displaystyle\\begin{array}{l}<br \/>\n\\neg {\\tt fireFightingCar6.isAtFireStation}\\ \\land\\\\ \\neg {\\tt fireFightingCar7.isAtFireStation}<br \/>\n\\end{array} \\)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p style=\"text-align: justify;\">Then, the obtained B-LTL formula is used in conjunction with the simulation platform\u00a0DESYRE to assess the probability that these goals is met in the specified time range (the simulation time\u00a0for each run was 4 months). By choosing the Monte Carlo option, Plasma-Lab was able to give us the\u00a0following estimation as a result on a given number of runs:<\/p>\n<p style=\"text-align: center;\"><strong>Prob(mean city area under fire \u2264 0.01%) \u2248 92.3%<\/strong><\/p>\n<hr \/>\n<h3 id=\"AdaptiveCAE\">A-RML models based on the CAE incubator example<\/h3>\n<p>We have design Adaptive RML models based on this CAE incubator example. The models are available in the following Plasma-Lab project: <a href=\"http:\/\/plasma-lab.gforge.inria.fr\/plasma_lab_examples\/SoS\/Adaptive_CAE.plasma\"><strong>Adaptive_CAE.plasma<\/strong><\/a>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Recently, in DANSE [ABL13], we adapt the SMC techniques to treat large heterogeneous systems like Systems of Systems. Among them, one finds systems integrating multiple heterogeneous distributed applications communicating over a shared network. We proposed to extend UPDM specification &#8211; the SoS specification &#8211; with some requirements that the SoS\u2026<\/p>\n<p> <a class=\"continue-reading-link\" href=\"https:\/\/project.inria.fr\/plasma-lab\/examples\/system-of-systems\/\"><span>Continue reading<\/span><i class=\"crycon-right-dir\"><\/i><\/a> <\/p>\n","protected":false},"author":232,"featured_media":0,"parent":236,"menu_order":0,"comment_status":"closed","ping_status":"open","template":"","meta":{"footnotes":""},"class_list":["post-704","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/project.inria.fr\/plasma-lab\/wp-json\/wp\/v2\/pages\/704","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/project.inria.fr\/plasma-lab\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/project.inria.fr\/plasma-lab\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/project.inria.fr\/plasma-lab\/wp-json\/wp\/v2\/users\/232"}],"replies":[{"embeddable":true,"href":"https:\/\/project.inria.fr\/plasma-lab\/wp-json\/wp\/v2\/comments?post=704"}],"version-history":[{"count":86,"href":"https:\/\/project.inria.fr\/plasma-lab\/wp-json\/wp\/v2\/pages\/704\/revisions"}],"predecessor-version":[{"id":1937,"href":"https:\/\/project.inria.fr\/plasma-lab\/wp-json\/wp\/v2\/pages\/704\/revisions\/1937"}],"up":[{"embeddable":true,"href":"https:\/\/project.inria.fr\/plasma-lab\/wp-json\/wp\/v2\/pages\/236"}],"wp:attachment":[{"href":"https:\/\/project.inria.fr\/plasma-lab\/wp-json\/wp\/v2\/media?parent=704"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}