{"id":38828141,"url":"https://github.com/mascanc/mosa2","last_synced_at":"2026-01-17T13:14:51.907Z","repository":{"id":189750272,"uuid":"118940468","full_name":"mascanc/MOSA2","owner":"mascanc","description":null,"archived":false,"fork":false,"pushed_at":"2019-06-14T07:56:13.000Z","size":6568,"stargazers_count":1,"open_issues_count":0,"forks_count":3,"subscribers_count":1,"default_branch":"master","last_synced_at":"2024-04-24T06:25:56.248Z","etag":null,"topics":["actors","conformance","healthcare","ihe","ihe-process","interoperability","profile","quality-attributes","sgam","smart-grid","smart-grid-privacy","solution-architecture","togaf","transaction"],"latest_commit_sha":null,"homepage":null,"language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/mascanc.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2018-01-25T16:46:59.000Z","updated_at":"2023-09-08T17:35:44.000Z","dependencies_parsed_at":null,"dependency_job_id":"810e7b8e-47c4-4748-82e8-4957c17d85ae","html_url":"https://github.com/mascanc/MOSA2","commit_stats":null,"previous_names":["mascanc/mosa2"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/mascanc/MOSA2","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mascanc%2FMOSA2","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mascanc%2FMOSA2/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mascanc%2FMOSA2/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mascanc%2FMOSA2/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/mascanc","download_url":"https://codeload.github.com/mascanc/MOSA2/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mascanc%2FMOSA2/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28508987,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-17T11:50:55.898Z","status":"ssl_error","status_checked_at":"2026-01-17T11:50:55.569Z","response_time":85,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["actors","conformance","healthcare","ihe","ihe-process","interoperability","profile","quality-attributes","sgam","smart-grid","smart-grid-privacy","solution-architecture","togaf","transaction"],"created_at":"2026-01-17T13:14:51.781Z","updated_at":"2026-01-17T13:14:51.865Z","avatar_url":"https://github.com/mascanc.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"# A Formalization of the IHE Process\n\nThe Integrating the Healthcare Enterprises, [IHE](http://www.ihe.net), established a process to pragmatically and securely achieve enterprise IT interoperability. The process ranges from business-oriented high-level system design and culminates in the verification of vendor solutions conformance. We formalized a solution design methodology that is somehow embedded in the process, and formalize it with the intent to ease dependency management, enable design automation and provide provably correct solutions. \n\n## The Process\n\nIHE consists of Building Blocks named Integration Profiles which aim at solving a specific clinical use case by means of one or more\ntransactions. Vendors implement actors and transactions and go to special events named _connectathons_ to test for conformance and interoperability. After connectathons, products are listed in a public registry (see [IHE Product Registry](https://ihe.net/IHE_Product_Registry/)) where\nproject coordinators can select the appropriate vendors for conformance with a specific Profile. \n\nA typical e-Health project is created by matching the use cases with the clinical use case that each profile solves. By _grouping_ profiles (i.e., merging the functionalities of each of them), additional profiles are created ready to be used, recursively. At the end of the process, the IT architecture \"emerges\" from the correlations among those building blocks selected by the architect and those who have a _mandatory_ grouping with others. In this project we gave a syntax to the actors and transactions (to avoid the use of english prosa) and we formalized the profile grouping function and the _mandatory grouping_ which we call \"TF Rules\". \n\nWe provided a formal account of such process. We firstly introduce the IHE language and its syntax, and then we sketch its semantics. \n\nThe language is implemented in Java, and provides extension points to be further evaluated. \n\n## Using the language\nDesign software architectures should not be part of an naive inspiration (the architect is not a poet, cit.), but it should be disciplined and repeatable, to have further evaluation ex-ante (i.e., before the deployment or even the implementation of the software), and ex-post (i.e., being software assets, also architectures need constant monitoring and refactoring). We want to assist the architect in that means: we provide a formal language to express architectural assets and a formal process to build the architecture, allowing external reviews, and providing an automatic tool that re-evaluates the refactored architecture to check if it is compliant with a given policy (coming, e.g., from a customer). In particular, security concerns, are always poorly evaluated (for instance, because there is a scarcity of security professionals). Our proposal embraces the [RMIAS](http://rmias.cardiff.ac.uk/) model to continuos improve and validate compliance with a given security policy set (of security policies).\n\nEach profile has one or more **merging rules**, defining which other profiles are needed in order to achieve a given functionality. Additional rules are added by the architect to fulfill the need of the architecture.  The following picture (see, IHE ITI TF Vol1, Figure 2-1) shows the profiles and their respective rules (the arrows) for some of the IHE ITI profiles. \n\n![IHE Basic Merging Rules](img/vol21.png)\n\n\n1. The architect starts by defining the _building blocks (BB)_, or use a library. For instance, the IHE technical framework provides building blocks used in healthcare projects [worldwide](https://www.google.com/maps/d/viewer?ie=UTF8\u0026hl=en\u0026oe=UTF8\u0026msa=0\u0026source=embed\u0026ll=-3.81666561775622e-14%2C155.390625\u0026spn=138.013795%2C352.265625\u0026z=1\u0026mid=1wx3-Ye3zDFPl0r6wU2OvxtcObc0), while [IES](http://iesaustria.at) provides building blocks to establish the Smart Grid, or the [Connecting the European Facility, CEF](https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL2018/About+CEF+building+blocks), providing building blocks to implement eServices in Europe (provided by the European Commission). \n2. The architects adds to the existing BB catalogue the BBs created for a new project (if applicable)\n3. The profiles which tackles security concerns are equipped with a list of values according with the RMIAS model, and quality attributes are either already available or added.\n4. The architect calls the Grouping function to automatically create the solution architecture which emerge by applying the merging rules\n\nThe following picture shows the interactions amongst the profiles of IHE. We see the centrality of ATNA and CT. The picture is obtained executing `TestITI.java` under the `test` directory. \n\n![ATNA rule](img/atna.png)\n\n\n\nAfter step 4, the grouping rule returns a newly created profile (which can be, recursively, used to build additional architectures) which represents the solution architecture. At this step, the quality attributes may be further formally evaluated with a theorem prover  (e.g. we use [Z3](https://github.com/Z3Prover/z3)). In this way, Z3 is used to find a path for a given goal, to prove _formally_, if a given architecture supports some specific requirements. \nAs example imagine to have two profiles P1, and P2. P1 guarantees a throughput of 300 messages per seconds, while P2 only 200 in scenario A, or 400 in scenario B, and the customer requires 290 messages per second. In complex architectures it is not obvious to formally prove that scenario B _always_ holds. Our solution systematically proves that the architecture can support the requirement.\n\nWe  adopted  a  commonly  agreed  model  of  information\nsecurity  as  the  base  security  model:  the  Reference\nModel for Information Assurance and Security ([RMIAS](http://rmias.cardiff.ac.uk/)).\nRMIAS identifies the following security aspects (dimensions)\nof an Information System: Life Cycle, Information Taxonomy\n(Classification), Security Goals and Countermeasures. RMIAS\nsupports mainly goal-based security management, as opposed\nto threat-based security management. Threat-based models are\napplicable mainly to live systems, requiring statistical data on\nthe  real  concrete  threats  as  experienced  by  such  systems.  A\ngoal-based oriented model better suits the aim of incorporating\nsecurity concerns early on in systems architecture, ie\nsecurity-by-design.\nFocusing  on  goals  allows\nsecurity experts to communicate with other stakeholders using\nconcepts that do not require technical knowledge. The grouped profile at the end of the process contains the necessary attributes to be further evaluated to apply the RMIAS. \n\n\n\n\nWhat makes this language different from the many existing? Our language implements the IHE process, as describe above. However it could be applicable for all the architecture models given in a modular style, such as [RAMI](https://ec.europa.eu/futurium/en/system/files/ged/a2-schweichhart-reference_architectural_model_industrie_4.0_rami_4.0.pdf) for the Industrial IoT (also known as Industry 4.0), or the [SGAM](https://de.wikipedia.org/wiki/Smart_Grid_Architecture_Model) for the Smart Electricity Grid. \n\n\n## The syntax\nThe syntax of the IHE process is defined in the following picture.\n\n![The syntax of the IHE Process](img/syntaxihe.png)\n\nWhere the security requirements \n\n![The syntax of the IHE Process](img/secre.png)\n\nWe start by identifying an architectural element (e.g., a Technical Framework like IT Infrastructure, Eye care) which is composed by one or more profiles (e.g., XDS, PIX). Each profile has actors, transactions, domains, quality attributes, and a specific function (will be clarified later). As example, the Consistent Time profile from the IHE TF Vol1 is rendered as follows\n\n```    \nProfile CT {\n\tName: \"CT\"\n\tDescription: \"Defines a mechanism to synchronize the time base between multiple actors and computers\"\n\tFeatures: \"Keep time in sync, using NTP\"\n\tFunction: \"Consistent time\"\n\n\tactors:\n\t    \"TimeClient\"\n\t    \"TimeServer\"\n\ttransactions:\n\t    (\"TimeClient\", \"ITI_1_Maintain_Time\", \"TimeServer\")\n\tdomains:\n\t    \"Infrastructure\"\n\tquality_attributes:\n\t\tct1: \"drift(1msec)\"\n\tsecurity_requirement:\n\t    sct1: {\n\t      Form: \"Electronic\"\n\t      Sensitivity: \"Public\"\n\t      Location: \"Any\"\n\t      Goal: \"Maintain Time\"\n\t      State: \"Transmission\"\n\t      Descr: \"Maintain Time using NTP\"\n\t      Category: \"Time Synchronization\"\n\t    }\n}\n```  \nTo express a grouping rule with another profile, we use, e.g., `time2 : \"*/PIX-\u003eTimeClient/CT\"`. Using this notation we express that _any actor implementing the PIX profile shall be grouped with the TimeClient actor for CT_.\n\nWe provided a semantics in a denotational style and we implemented it. The outcome of the encoding is a set of Java classes that enables the analysis and the automatic construction of solution architecture.\n\nAs example, after selecting the relevant profiles matching the use cases with the clinical use cases for each profile, the architect could use our tool to automate the creation of the solution architecture by applying the TF Rules accordingly. The resulting list of actors, transactions, and profiles can subsequently applied recursively to more architectures. The Java implementation of the IHE TF Framework is as example under the directory `Samples`. \n\nQuality attributes resutling in the compilation of the IHE Process could be further refined by the architect, and evaluated automatically by a tool. By expressing them in SMT-LIB, any tool like Z3 could interpret them and provide formal guarantees that the solution architecture fulfills the quality attribute required by the customer. \n\nThis is ascreenshot of the IDE (using xText and xTend)\n\n![Editing lihe](img/ide.png)\n\nA sample execution of the test `TestCentralRegistry` (available under the `Language` directory) is as follows. \n\n```\nGROUP: adding Name: CLINIC Actors:  ContentCreator ContentConsumer ContentRecipient\nGROUP: resolving dependency\nGoing to resolve dependency on ABB named CLINIC\nFor actors: \n   ContentCreator\n   ContentConsumer\n   ContentRecipient\nFor rules: \n   */XDS-\u003eSN/ATNA\n   */Clinic-\u003eXServiceUser/XUA\n   */Clinic-\u003eSN/ATNA\n   */ExtSource-\u003eSN/ATNA\nEvaluating rule [*/XDS-\u003eSN/ATNA] with actor ContentCreator and profile CLINIC\nEvaluating rule [*/Clinic-\u003eXServiceUser/XUA] with actor ContentCreator and profile CLINIC\nEvaluating rule [*/Clinic-\u003eSN/ATNA] with actor ContentCreator and profile CLINIC\nEvaluating rule [*/ExtSource-\u003eSN/ATNA] with actor ContentCreator and profile CLINIC\nGROUP: resolved 0 dependencies\nGROUP: adding Name: XDS Actors:  Consumer Source Registry Repository\nGROUP: resolving dependency\nGoing to resolve dependency on ABB named XDS\nFor actors: \n   Consumer\n   Source\n   Registry\n   Repository\nFor rules: \n   */XDS-\u003eSN/ATNA\n   */Clinic-\u003eXServiceUser/XUA\n   */Clinic-\u003eSN/ATNA\n   */ExtSource-\u003eSN/ATNA\nEvaluating rule [*/XDS-\u003eSN/ATNA] with actor Consumer and profile XDS\nRule matches!\nGoing to resolve dependency on ABB named ATNA\nFor actors: \n   SN\n   ARR\nFor rules: \n   */XDS-\u003eSN/ATNA\n   */Clinic-\u003eXServiceUser/XUA\n   */Clinic-\u003eSN/ATNA\n   */ExtSource-\u003eSN/ATNA\nEvaluating rule [*/XDS-\u003eSN/ATNA] with actor SN and profile ATNA\nEvaluating rule [*/Clinic-\u003eXServiceUser/XUA] with actor SN and profile ATNA\nEvaluating rule [*/Clinic-\u003eSN/ATNA] with actor SN and profile ATNA\nEvaluating rule [*/ExtSource-\u003eSN/ATNA] with actor SN and profile ATNA\nABB To return: null\nEvaluating rule [*/Clinic-\u003eXServiceUser/XUA] with actor Consumer and profile XDS\nEvaluating rule [*/Clinic-\u003eSN/ATNA] with actor Consumer and profile XDS\nEvaluating rule [*/ExtSource-\u003eSN/ATNA] with actor Consumer and profile XDS\nGROUP: resolved 1 dependencies\nResolved dependency Name: ATNA Actors:  SN ARR for ABB Name: XDS Actors:  Consumer Source Registry Repository\nEvaluating quality attributes\nRecursively calling group(XDS,ATNA)\nGROUP: adding Name: EXTSOURCE Actors:  ContentCreator ContentRecipient\nGROUP: resolving dependency\nGoing to resolve dependency on ABB named EXTSOURCE\nFor actors: \n   ContentCreator\n   ContentRecipient\nFor rules: \n   */XDS-\u003eSN/ATNA\n   */Clinic-\u003eXServiceUser/XUA\n   */Clinic-\u003eSN/ATNA\n   */ExtSource-\u003eSN/ATNA\nEvaluating rule [*/XDS-\u003eSN/ATNA] with actor ContentCreator and profile EXTSOURCE\nEvaluating rule [*/Clinic-\u003eXServiceUser/XUA] with actor ContentCreator and profile EXTSOURCE\nEvaluating rule [*/Clinic-\u003eSN/ATNA] with actor ContentCreator and profile EXTSOURCE\nEvaluating rule [*/ExtSource-\u003eSN/ATNA] with actor ContentCreator and profile EXTSOURCE\nGROUP: resolved 0 dependencies\nAssembling the ABB\nHit ENTER\n\n   _______________________________________________________________________________________________________________________________________________________________________________________\n   | ID    | Form      | Sensitivity  | Location            | State       | Goal          | Countermeasure                                      | Category                                |\n   |======================================================================================================================================================================================|\n1. | satna1| Electronic| Condfidential| Controlled          | Transmission|               | TLS Channels                                        | Data confidentiality transfer protection|\n2. | prtl1 | Electronic| Confidential | Controlled          | Transit     | Authentication| The portal authenticates user via a login screen    | User Authentication                     |\n3. | satna2| Electronic| Confidential | Controlled          | Transmission| Accountability| rfc5424 syslog and DICOM PS A.5                     | Accountability                          |\n4. | es1   | Electronic| Confidential | Partially Controlled| Transmission| Authentication| Authenticate the user who is submitting the document| Data integrity transfer protection      |\n5. | xds1  | Electronic|              | Any                 |             |               |                                                     |                                         |\n6. |       |           |              |                     |             |               |                                                     |                                         |\n\n```\n\nFor instance, if a security policy states \"All the Authentication means shall be level 2 (Strong)\". A projection on this table `WHERE Goal='Authentication' AND Level\u003c2` returns 1 row, the 4th, which is not fulfilling the policy. \n\nThe security requirements can be accessed as \n\n```\ngroupedABB.getSecurityRequirements().stream().forEach(x -\u003e {\n\t// evaluate x\n});\n\n```\nwhere `groupedABB` is the result of Group. See the tests provided for more information.\nThe architect is left free to evaluate the security requirements as he wants. We provided in our technical report a sigma notation (which is inspired by the relational algebra).  \n\n### Evaluating with Z3\nQuality attributes can be further evaluated with Z3, as previously described. \nBy defining the quality attributes in a format which can be evaluated in SMT-LIB, e.g., \n\n```\nquality_attributes:\n        pix1: \"(define-fun pi.levenshtein.match_sec () Int 200)\"\n```\n(in this example: the IHE PIX profile that can match up to 200 patients per seconds using the Levenshtein algorithm) quality attributes are declared as _constants_. Once the database of quality attribute is defined, the architect could further evaluate the goal matching the customer's requests, e.g., \n\n```\n;\n; Definition of the goal. Is our architecture capable of doing x reads per second?\n;\n\n(echo \"Declaring the GOAL\")\n(declare-fun secure_reads_per_second () Int)\n\n;\n; Algorithms. We put in OR the quality attributes, and we AND the overall\n;\n(echo \"Declaring the algorithms\")\n(define-fun throughput_pi_read() Bool(\n    or (\u003e pi.levenshtein.match_sec secure_reads_per_second) (\u003e pi.soundex.match_sec secure_reads_per_second)\n))\n\n(define-fun throughput_sr_read() Bool(\n    or (\u003e sr.hw.hs secure_reads_per_second) (\u003e sr.sw.hs secure_reads_per_second)\n\n))\n\n(define-fun throughput_ds_read() Bool(\n    or (\u003e ds.db.read.sec secure_reads_per_second) (\u003e ds.fs.read.sec secure_reads_per_second)\n\n))\n\n;\n; Declaring the Overall function\n;\n\n\n(define-fun throughput_total() Bool(\n    and throughput_pi_read throughput_ds_read throughput_sr_read\n))\n\n;\n; Adding the assertions to the stack. This is the main goal of the\n; evaluation of the quality attributes: how many reads per second\n;\n(assert throughput_total)\n(assert (and (\u003e secure_reads_per_second 30) (\u003c secure_reads_per_second 32)))\n\n\n(echo \"Checking satisifiability\")\n\n(check-sat)\n\n(echo \"The architecture supports the following value\")\n(get-value (secure_reads_per_second))\n(get-proof)\n(get-model)\n(get-info :all-statistics)\n``` \n\nA sample transcript is as follows. \n\n```\nmax@spirit6 ~/Documents/GitHub/TOGAFIHE/sampleZ3 $ z3 test.rs\nDeclaring the quality attributes of Profile PI\nDeclaring pi.levenshtein.match_score\nDeclaring pi.levenshtein.match_sec\nDeclaring pi.soundex.match_score\nDeclaring pi.soundex.match_sec\nDeclaring the quality attributes of Profile SR\nDeclaring sr.hw.hs\nDeclaring sr.sw.hs\nDeclaring the quality attributes of Profile DS\nDeclaring ds.db.write.sec\nDeclaring ds.db.read.sec\nDeclaring ds.fs.write.sec\nDeclaring ds.fs.read.sec\nDeclaring the GOAL\nDeclaring the algorithms\nChecking satisifiability\nsat\nThe architecture supports the following value\n((secure_reads_per_second 31))\n(error \"line 92 column 10: proof is not available\")\n(model\n  (define-fun secure_reads_per_second () Int\n    31)\n)\n(:arith-assert-lower 1\n :arith-assert-upper 4\n :del-clause         3\n :final-checks       1\n :max-memory         1.10\n :memory             1.08\n :mk-bool-var        9\n :mk-clause          3\n :num-allocs         3468\n :num-checks         1\n :rlimit-count       354\n :time               0.01)\n```\n\nThe transcript shows that the architecture supports the requirement of 30 and 32 reads per seconds. \n\n## Applying the process to TOGAF and SGAM\n\nThe IHE process has been executed in healthcare since 17 years worldwide, and almost all e-Health projects relies on the IHE profiles. \nWe believe that this process can be applied to other sectors successfully. We applied the process to a TOGAF-like architecture and to the SGAM (Smart Grid Architectural Model) in e-Government (throught the http://www.e-sens.eu with application to the ISA EIRA https://joinup.ec.europa.eu/solution/eira) and to Energy (using the technical framework provided by http://www.iesaustria.at). We believe that the IHE process could leverage the sustainability given by the TOGAF approach, and by the selection and use case representation from the SGAM. Viceversa, the SGAM and the EIRA could benefit from the IHE process by creating emerging solution architecture just running the grouping function, and further formally analyzing with Z3. This is in particular true for the SGAM in which the BAP must not have options. There will be many BAPs to choose from, and thus an automatic tool like the one presented could ease the work of the IT architect in selecting and analyzing the best architecture for the system.\n\n## Security by design for Cooperative Intelligent Transport Systems (C-ITS)\n\nThe IHE process holds the flexibility to be used in other verticals. C-ITS is one of the examples. Being C-ITS the basis of Connected and Cooperative Automated Driving (CCAD/CCAM), interoperability is the key. Road Side Units from all the road operators shall send and receive infomobility messages from on board units from many car manufacturers. Hence, to foster interoperbaility, standards exists. However, those standards are coming from different SDOs such as IEEE 1609, ETSI ITS, ISO, CEN, having different lifecycle. The IHE process can be used to attain the governance needed to provide technological and economical sustainability of systems.\n\nFor instance, some basic profiles may be introduced, to share data from vehicles to infrastructure, securely. As an example, vehicles may share their kinematic data (such as speed, curvature), or the road operator may share the Safety-Related Traffic Information of Road Works Warning Ahead (Hazardous Location Notification). This information may come from a backend in a road operator infrastructure. This case can be implemented by introducing the following profiles. \n\n* Audit Trail and Node Autentication (ATNA)\n* Exchange of ITS-S Messages (EIM)\n* Road Works Warning (RWW)\n* Share Kinematic Data (SKD)\n* RSU to Backend (R2B)\n\nIn MOSAA, the most representative integration profile for the system, EIM, can be rendered as follows\n\n```    \nProfile EIM {\n\tName: \"EIM\"\n\tDescription: \"Defines a mechanism to exchange ITS-S Messages\"\n\tFeatures: \"Send CAM, DENM\"\n\tFunction: \"Send messages over DSRC\"\n\n\tactors:\n\t    \"Sending_ITS-S\"\n\t    \"Receiving_ITS-S\"\n\ttransactions:\n\t    (\"C-ITS-03_Send_Message\", \"C-ITS-04_Send_Message_5G\")\n\tdomains:\n\t    \"Infrastructure\"\n\tquality_attributes:\n\t\tct1: \"max_message_delay(50msec)\"\n\tsecurity_requirement:\n\t    sct1: {\n\t      Form: \"Electronic\"\n\t      Sensitivity: \"Public\"\n\t      Location: \"Any\"\n\t      Goal: \"Share Infomobility Messages\"\n\t      State: \"Transmission\"\n\t      Descr: \"Share message\"\n\t      Category: \"Information Delivery\"\n\t    }\n}\n```\nEIM implements ETSI ITS 103 097, and it has a mandatory grouping rule with ATNA, such as `EIM-\u003eATNA`. When grouped with ATNA, as usual, the messages look like: \n\n* Who: identity based on the subject in the ITS-S’s enrollment certificate\n* What: the string ”C-ITS-03” indicating the transaction type\n* When: the timestamp of the transaction\n* Resource: the value of the (Provider Service Identifier)(PSID) from the Authorization Certificate\n* Server: the StationID of the ITS-S\n\nSimilarly, in MOSAA, the other profiles can be defined, and an architecture can be built.\n\n## Using the library\nThe system is still in development. Clone the repository and import the project in Eclipse (make sure to have xtext and xtend installed, I recommend using a DSL-distribution). After eclipse recognizes the nature of the project (Xtext nature), right click on the com.spirit.ihe project and Run As... -\u003e Eclipse Application, and this should run the editor. Before make sure to have right clicked on the grammar file `IHE.xtext`, and Run As... -\u003e Create Xtext artifacts. Edit the IHE file in the editor, and save it. In the `src-gen` it should have created the java source code for your architecture. \n\nCopy/Paste those generated package in a Java Project (I use a separate Eclipse) where the semantics project is available. Then you can check the `test` directory for further information. Specifically the `TestCentralRegistry` describes the steps used to evaluate the architecture. \n\n## Known Bugs\n* Provide a full eclipse plugin\n* Translate the solution architecture in SMT-LIB\n* The profile name shall contain only [a-z][A-Z] characters\n\n### Contacts\n\n* [github/mascanc](https://github.com/mascanc)\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmascanc%2Fmosa2","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmascanc%2Fmosa2","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmascanc%2Fmosa2/lists"}