User's Guide (One Page)
About PHENOM Portal
Not Just another Modeling Tool
The Skayl team has been practicing this form of data modeling since 2011...before Skayl even existed. Our team worked together on a project developing the modeling technology as well as an initial model. After one particular model update cycle, a couple of million dollars worth of work was lost. A minor change in the model resulted in the need to reproduce a lot of work. To make matters worse, this could have been avoided with some specialized tooling. Thus the idea of PHENOM was born. At that moment, we committed to make sure this amount of loss would not occur again.
Skayl did not aspire to be a tool vendor. We developed the tool we needed to data model and decided to share it with others. PHENOM has continued to grow as our customer needs change.
The Initial Release of PHENOM
The original PHENOM release was based on the idea of "one domain specific data model per server." Skayl envisioned hosting many different DSDMs for different purposes. One server would exist for the Aerospace and Defense community. Another server would exist for medical technology, etc. It wasn't long before users wanted to upload their own models and import their own content. Thus the tool (and our vision for us) started to evolve.
Release Cycle
We’re constantly working to improve and extend PHENOM, both the software and the underlying data models and content. We are always making little tweaks to make things simpler for you, but of course, we have major new feature additions planned as well.
Your Dashboard will list the most recent updates made, and we’ll send out emails when there is major update available. Of course, if you use the Skayl-hosted version of PHENOM, the updates will automatically appear the next time you login. If you are an enterprise user, your IT department will periodically update your PHENOM instance to the latest version.
Getting Started
Welcome to PHENOM by Skayl!
If you're new to PHENOM, or if you haven't had your introductory training yet, this page can help get you oriented to some of the tools basic features. Click on the Getting Started link below to see a tree of links to instructions on beginning functionality within PHENOM, including login, settings, navigating and editing.
Introductory Topics
Login
PHENOM users will be prompted for a username and password upon login. Each user should have a unique username. If a user has set up Two-Factor Authentication previously, this authentication will be requested after the username and password is verified.
Requesting an Account
To request a new user account to PHENOM:
- Contact your organization's PHENOM administrator and request access
or
- email INQUIRIES@SKAYL.COM
- Include your organization's name, your full name, your email address, phone number in the email
Logging Into PHENOM
Login Using Username and Password
- Go to your PHENOM portal URL
- Enter your username
- Enter your password (of this is your first time logging in, enter the password provided to you. Once you are logged in, you can change your password in Settings)
Logging in with Two-Factor Authentication
Once you have set up Two-Factor Authentication, you will need access to your mobile device to login to your PHENOM account.
- At the Login prompt, enter your PHENOM username and password
- Upon successful password verification, PHENOM will request your Authenticator passcode
- Open the Authenticator app on your phone
- Under PHENOM, you will find the Authenticator passcode, enter this code into PHENOM
- You are now logged into PHENOM
Requesting a New Password
To request a new password to PHENOM:
On the login page, click “request a new password”:
Enter your username and click “Request Reset”:
After a few minutes you should receive a password reset email. Copy paste the link into your web browser (if it redirects to the login page, copy paste the link and refresh the page again):
Enter a new password, click “Reset Password”.
Login with your username and new password.
Basic Navigation
PHENOM has five primary modes that are accessed along the left hand side.
The Dashboard provides a high level overview of your current model, recent changes to the model, and a quick-link section for accessing different functions in PHENOM.
To access the dashboard, click on the following icon:
The Data Modeling area is where all the data model entities, associations, and interface documentation is developed.
To access data modeling, click on the following icon:
The Integration Modeling area is where the integration model is developed.
To access integration modeling, click on the following icon:
The Generate area is where users go to export various products from PHENOM. These products include data models, diagrams, and integration software.
To access the generate area, click on the following icon:
The Manage Models area is where users go to switch their current project, create new projects, add models to their current project, and import new models.
To access the manage model area, click on the following icon:
Throughout PHENOM, a NAgivation Tree (NavTree) is used to organize model content. It will be explained in more detail on its own page.
Dashboard
PHENOM's Dashboard is the first screen users will see when they log in. The Dashboard communicates the latest general analytics regarding the core model, recent changes to the model, and the most recent as well as archived Release Notes, containing a summary of the latest features added to PHENOM. The dashboard also provides a series of Quick Links - these are common actions intended to help the novice user find what they need easily.
Using the Dashboard
When you first log into PHENOM, you will see your personal dashboard. This section will show you the key elements of the dashboard.
Across the very top of your dashboard, you find your login name as well as the name of your current branch. Read more about Branches. Since PHENOM allows you to change branches and work in other models, this is a helpful tool so you can be sure that you are editing the branch of the model you expect.
On the left-hand side, you will see the navigation links. This is where you can choose between the major functions of PHENOM.
NOTE: This interface is expected to change. While it may look different and the currently listed commands may be allocated to another place on the website, the function remains the same. Use this area to switch between the main modes of operation of the site.
Across the top of the dashboard, you see the project overview. This is a live count of the number of entities, attributes, and views currently managed in your branch. The shapes, sizes and proportions of the regions in the overview can provide a high-level idea of model quality and how the model is currently used.
The next section is a series of Quick Links. These are common actions that are commonly performed in PHENOM and is intended to help a novice user quickly navigate to the correct function.
Finally, you see the notification area typically used to announce the features added in the latest release. When you log in, you can go here to find out what has changed since the last update of the software.
Search Bar
PHENOM's Search bar is a global search utility that can be used to find any model node within the current model.
Using the Search Bar
When you login into PHENOM, you will notice the search bar as slim text input located at the top of the page.
When clicking into the field, you may begin typing your search query. While typing, there will be an an active search processing for your query (This is indicated by the spinning logo below the search field).
If no results can be found for your search, there will be a dialog stating that there are no results.
When results are found, you will be prompted with a result that will look similar to the one below.
Double clicking on the category header or single clicking on the category expand arrow will expand or collapse the category results.
Data Modeling
The details tab is where most of the detailed model editing is done. Although selecting the details tab directly does very little, this is where the properties appear once an element has been selected from the NavTree.
Diagrams are a very easy way to visualize models and explore their connectivity. A modeling tool would not be complete without some means of building diagrams. While constructing PHENOM's diagramming engine, users expressed their desire for a "modeling scratchpad" capability. This concept allows users to build model content without immediately affecting the data model. This makes it possible to experiment with different modeling ideas without adding a bunch of intermediate content to the model. The new elements become official model content once they are "committed."
Beyond modeling new elements and patterns, the diagram tool can be used to build interface documentation. This functions oppositely from PHENOM's typical mode of documentation. Instead of start with the most specific details and then adding context, this view editing tool starts with the broadest context and narrows down to the most specific details. This approach is difficult to use unless you know the data model.
Rapidly check the overall health of your data model using PHENOM's Health Check. It runs 19 different tests against the model.
Some of the health checks provide tools to help users fix errors.
These are tools that provide additional insight into the model. It can show the distribution of entities and attributes used in the documentation. This helps identify areas of the model where refactoring activities can provide the greatest benefit.
The Meridian Map is a type of ribbon diagram that shows the semantic alignment of a collection of views. Drag up to 50 views into the Meridian Map, and it will quickly render the a graph showing all of the 100% semantic matches.
By default, this alignment works at the conceptual level. This means that a latitude position will map to a longitude position. In order to further filter using the measurement information, make sure that "Logical Matches Only" is selected.
The View Trace tool allows users to map a set of views (one or more) to another set of views (one or more). Although the data model automates the View Trace process, there are times when it is necessary to map dissimilar semantics. View Trace is the primary mechanism for overriding semantic mappings.
Although loading FACE XMI models (.face files) is the primary mechanism for importing bulk data into PHENOM, the import section has some helpful tools for importing data that may not conform to this default format.
PHENOM has the ability to import: Entities, Associations, Views, Enumerations, Constraints, and Platform Types.
Data Model Details
From the Details tab, users can review detailed information about model nodes, create new nodes, and edit or delete existing nodes. Not all of types of nodes can be created, edited, or deleted, and there are some nodes which will not appear in this user interface. The nodes accessible through the details tab and their available user interactions are summarized below. Note that from anywhere in PHENOM, if the user double clicks on a node, she/he will be redirected to the details page of the selected node.
Page format
All details pages are built in the same way:
- All the action buttons (Save, Reset, Delete) are located in the sub-tab bar in the top right corner.
- The top right corner of the page provides indications about
- When the element was last modified and by whom
- The model the element belongs to
- The Changesets selected
Most details pages also allow the user to edit/view the tags applied to the element
Constraints limit the possible values of a view attribute to which they are applied. The nature of the constraint is based on the primitive type employed by the view attribute.
Entities and associations are the basic building blocks of a Domain Specific Data Model (DSDM); they represent the different real-world entities and relationships present in the domain as well as those entities' and relationship's properties.
Measurements are a part of the Logical Data Model (LDM) and their properties can be edited within PHENOM.
LDM level systems determine the properties of measurements used in the project and direct the conversion between them.
Observables are part of the Shared Data (SDM) and cannot be created or deleted.
PHENOM's Packages function like folders that help users organize components of the project as well as their own files and content.
Platform Types are used to relate a View Attribute to an LDM Measurement. Platform Enumerations are Platform Types that have Platform Enumeration Literals relating to the realized Measurement's LDM Enumeration Labels.
Reference Point is used to provide a basis for locating and/or orienting a Measurement System.
Semantic matching of documented view attribute paths is the process that matches message fields of same or similar semantic meaning to each other to facilitate and, ultimately, automate the process of message set integration.
Platform Data Model (PDM) views represent collections of data fields which are collected and transmitted in a defined message interface.
View attributes represent the data fields of a particular message and are used to document the contents of the same.
Entity and Association
Entities and Associations are the basic building blocks of a Domain Specific Data Model (DSDM); they represent the different real-world entities and relationships present in the domain as well as those entities' and relationship's properties.
Creating an Entity
Click on the Create menu at the top left of PHENOM and select Conceptual > Entity from the drop-down. The only entry required to save a new Entity is a valid name. Once all fields are filled in, clicking the SAVE button at the top of the page will create the new Entity.
By default, the new Entity will be created in the PhenomEntities package. Once created, a few new attributes can be edited: entity attributes, associated entities, tags...
Adding/Editing Attributes
To add a new attribute to an Entity, click the create button that appears at the bottom of the attributes section to add a new row. Attributes require a valid name and type.
Any attributes added or edited on the Entity/Association page will not be saved until the save button in the upper right corner is clicked.
Adding/Editing Associated Entities
To add a new associated entity to an entity, click the create button that appears at the bottom of the associated entities section to add two new rows. Associated Entities require a valid name and type.
 | When you click "Create" in the Associated Entity section for the first time, you will need to add two associated entities. Adding Associated Entity to an Entity will convert the Entity to an Association (since you're associating entities to each other) |
Any associated entities added or edited on the Entity/Association page will not be saved until the save button in the upper right corner is clicked.
Moving an Attribute
For refactoring or other purposes, the user is able to move an Attribute from its parent Entity/Association to another. To initiate, the process, the user can either click on the dedicated button at the end of the attribute row or right-click on the Attribute in the NavTree.
In the dialog that appears, the user needs to select the Entity to which to move the selected Attribute.
A common reason for moving an attribute is refactoring previous work. For example, let's say AirVehivleType.engineTemperature used to represent the engine temperature of an air vehicle. To better document the domain, an Engine entity can be created and composed in AirVehicleType, AirVehicleType.engine, then AirVehicleType.engineTemperature can be moved to its sibling AirVehivleType.engine. The attribute can later be renamed so that the final entity composition becomes AirVehicleType.engine.temperature. As this is a pretty common use case, the Attribute Move dialog has an option to compose the target Entity/Association in the current Entity/Association if it was not already done.
Deleting/Deprecating an Entity or an Attribute
To delete, an individual Attribute or an Associated Entity, drag it from its table to the trashcan in the mid-right part of the page:
The delete button in the upper right will delete the entire Entity/Association and all of its children:
To avoid breaking the current project or someone else's, an element can only be deleted under a certain set of circumstances:
- Entities and associations cannot be deleted if they are referenced as a type in an attribute or associated entity.
- Entities, associations, and their children cannot be deleted if:
- They were pushed to a parent
- They also exist in a parent branch.
- Attributes and associated entities cannot be deleted if they are used in a view characteristic path.
- When deleting an associated entity, if there's only two associated entities in the association, both will be deleted.
When making a deletion, a confirmation popup will appear. If the element is safe the delete, the user may confirm the action. If the element being deleted breaks one or more of these rules, these will be displayed to the user including the origin of the issue and the user will be able to either cancel or deprecate the element. Doing so, the element will be flagged in the project as deprecated and every time the user will try to use that element, she/he will see the warning flag and should refrain from using it.
Note: Even if an element is safe to delete, the user can choose to deprecate it instead of deleting it.
| Deletion of an Entity/Association happens immediately after confirming deletion. Deletion of Attributes/Associated Entities happens after clicking "save". |
Additional Fields
The details page of an Entity/Association displays some non-editable fields.
Last Modified By
The last editor and edit date time can be viewed here is displayed in the top right corner.
Attributes → Views
If an attribute is used by a View Characteristic, an expandable list appears in the Projectors column.
Composed In
Entities/Associations that have attributes of type the currently viewed entity/association will appear in the "Composed in" section.
Associated In
Associations that have associated entities of type the currently viewed entity/association will appear in the "Associated in" section.
View
Creating & Editing Views
To create a View, select the corresponding option from the Create > Platform dropdown menu.
The only field required to save a new view is a valid and unique name.
If you want the view to be saved in a package other than the default option, choose a package in the Parent Package dropdown, which defaults to the PDM package currently selected, or PhenomViews.
A view can be Nesting or Composite. The toggle may lock depending on the view field contents.
Once the View has been created using the Save button in the top right corner, the user will be able to add View Attributes and tags to it.
Composite Views
A Composite View allows the user to declare that a given template is intended to be a composite template. In a Composite View, all view fields must:
- Be nesting fields
- Point to views that have a uniform projected characteristic across all of their internal fields
Nesting Views
A Nesting View allows the user to add both nesting and non-nesting fields. In a Nesting View, all view fields must:
- Point to a view that has a uniform projected characteristic across all of its internal fields.
Managing View Characteristics
View characteristics can be added to Views via the "Create" and "Add Nesting" buttons in the Attributes section. The "Create" button will redirect the user to View Attribute details page and the "Add Nesting" button will add a row to the table for inline editing.
After adding view characteristics, they will show up in the Attributes table. For each row, the user can click on the following links:
- Name: link to the View Attribute's page
- Measurement/View: link to the Measurement's or nested view page
- Path/Perspective: link to any of the path hop's page
- Semantic Matches: opens the Semantic Matches dialog with semantic matches to the selected view characteristic.
The view characteristics can be reorganized in the table by dragging and dropping the rows into a desired order:
- Simply select the row and drag it:
- Hover the selected row over its destination and release it:
View Attribute
A View Attribute can be also referred to as view characteristic or view field.
Creating & Editing View Attributes
To create a new View Attribute, click the "Create" button in the Attributes section of a View details page:
A View Attribute must have:
- A unique and conformant name
- An Observable
- A Measurement
- A path
Name
The attribute's name must consist of letters, numbers, or underscores and start with a letter.
Observable/Measurement
The user can either start by selecting an Observable and then the Measurement - the Measurement list will be filtered to the Measurements realizing the selected Observable - or select the Measurement first which will automatically select the Observable the Measurement realizes.
Platform Type
Once the Measurement is selected, the user needs to either create a new Platform Type or select an existing one by clicking "Select Platform Type"
Path
The final step in creating a View Attribute is to add a semantic path using the path builder. The path is built hop by hop, starting with the entity/association attribute typing the selected observable. Each hop must be committed by clicking the checkmark before being able to move to the next. The last selected hop can be removed by clicking the x next to the new hop box. The current path of the attribute is rendered under the Path section title.
After committing a hop, if there are additional hops that can be added, they will appear in the dropdown list, otherwise the text "No Possible Options" will appear.
The circling arrow and the X next to the commit button respectively resets and cleans the path.
Destructure Linkers
Destructure Linkers are available when a view attribute has a IDL Struct Platform Type. The option is present on the view attribute page.
When enabling the Destructure Linker toggle, some additional options will pop up such as a Destructure Reference radio button and a option to create a new, or select an existing Destructure Linker. It's only possible to select a single IDL Composition as a Destructure Reference.
After saving when selecting a Reference and a Linker, the parent view of the attribute will now update it's 'Query and Template Preview' to include the new Destructure Linker
Creating & Editing Nesting View Attributes
To create a new Nesting View Attribute, click the "Add Nesting" button in the Attributes section of a View details page:
A Nesting View Attribute must have:
- A unique and conformant name
- A View
- A path
- Be Privately Scoped or Foreign Reference
Nesting View Attributes are created and edited inline. Any new or updated Nesting View Attributes will be saved when the user clicks on the "Save" button either for the row or for the entire View.
A Nesting View Attribute must point to a view with a uniform projected characteristic. The foreign referenced Nesting View Attribute's uniform projected characteristic must match the type of the last hop of the perspective path used by any field that nests it.
A Nesting View Attribute can either be a "Foreign Reference" or a "Privately Scoped" attribute. If the Private checkbox is checked, then the attribute is marked as "Privately Scoped" otherwise, it is marked as "Foreign Reference". New Nesting View Attribute defaults to "Privately Scoped".
Note that when switching from a Nesting to a Composite View, the Path/Perspective attribute and the Private attribute are cleared on save.
Package
A Primer on Packages
Packages function like folders that help users organize elements of the project. Each package has a type:
- Conceptual
- Logical
- Platform
- Service (UoP)
- Integration
- Deployment
The type of the package limits the scope of elements it can contain: Conceptual packages can contain only Observables, Entities, and Associations; Logical packages can contain only Measurements, Measurement Systems, Coordinate Systems...; etc. Each package may also contain additional packages of its own type, with the exception of the root level which includes packages of all types.
Creating a Package
To create a package, the user needs to either select the corresponding option in the Create dropdown menu or right-click on a package in the NavTree.
The user needs fill in the Package's name (which must be unique) and description.
If the user right-clicked on a package from the NavTree, the type and parent package will be pre-filled with the selected package. If not, the user needs to select a type which will filter the parent package list.
Navigating Packages
Using the NavTree on the left, packages are structured and navigated just like file folders. In order to expand or collapse a given package, left-click on the caret icon. Packages may be nested many levels deep.
Packages can be moved and reordered simply by drag-and-drop interaction in the NavTree. While dragging a folder to a new location, the NavTree will show either a green checkmark (indicating that this is a valid place to drop) or a red x (indicated that this is an invalid place to drop). As described above, a package must be dropped on a package of the same type.
Observable
Observable are a list of (mostly) distinct concepts that may be used in a data model to build entity and associations.
An Observable is characterized by three things:
- GUID - the Globally Unique IDentifier is a critical part of the definition. Although this is the true identity of the Observable, this form of information is not terribly useful to a human user.
- Name - this is the label that helps a user understand what the observable is intended to represent
- Description - the name is not always sufficient so the description provides amplifying information to further clarify what the observable is intended to represent.
Single Observable Modeling
Single Observable Modeling is when the SDM, a DSDM, or a USM is developed to follow the Single Observable Constraint in Section J.7.1. The Single Observable Constraint limits Conceptual Entities to composing at most one element of a single Observable type. Models that follow the Single Observable Constraint provide a clearer understanding of Entities by reducing the likelihood of semantic information being embedded in the multiple composition of Observables. This is considered a data modeling best practice.
List of Observables
Measurement
Measurements can either be standard or enumerated. The process to create/edit the two types is slightly different. This page describes both.
Creating & Editing Measurements
To create a Measurement, select the corresponding option from the Create > Logical dropdown menu.
There are a few requirements to create a Measurement, it needs to have:
- A unique name
- An observable
- A Measurement system
- At least one Measurement Axis
Observable
The user must choose an Observable from the dropdown. Once selected, its characteristics will be displayed. Clicking the icon in the top right corner of the box will redirect the user to the details page of the element. By clicking on the link, the user will be redirected to the new page and lose all unsaved changes.
To reset the field, the user can click on the round arrow on the right of the drop down field.
Measurement System
A Measurement must have a Measurement System. When the user selects a Measurement System from the dropdown, its characteristics will be displayed: Measurement System Axis/Axes, Coordinate System, and Coordinate System Axis/Axes. Clicking the icon in the top right corner of each box will redirect the user to the details page of the element. By clicking on the link, the user will be redirected to the new page and lose all unsaved changes.
To reset the field, the user can click on the round arrow on the right of the drop down field.
Measurement Axis
A Measurement must have as many Measurement Axes as are included in the selected Measurement System. This constraint is only applied on save so while editing, the block to the right of the dropdown provides an indication as to how the user is doing.
The user can either select an existing Measurement Axis or select <New> to create a new one. In either case, once a selection has been made, a new collapsible block will be displayed. The user can also open the Measurement Axis details page and remove it from the list.
New Measurement Axis
After selecting <New> from the Measurement Axis dropdown, the user can fill in the creation form. The user must provide a unique name and a Measurement System Axis, the other fiels are optional.
Measurement System Axis
The user must select a Measurement System Axis. Only Measurement System Axes referenced by the Measurement System selected above on the Measurement page are available in the dropdown. If the user selects an existing System Axis that includes a Measurement System Axis not referenced by the Measurement System, an error will be displayed.
Value Type Unit
The user may add one or more Value Type Unit(s) to the Measurement Axis. To create a Value Type Unit, the user must select a Value Type and a Unit. Constraints are optional and the user may choose and existing one or create a new one. Constraint creation is detailed here.
Platform Types
This section is not editable. Once the Measurement is created, the table will be filled in with Platform Types realizing the Measurement.
Conversions
This section is not editable. Once the Measurement is created, the table will be filled with Conversions which source or target is the selected Measurement.
Creating & Editing Enumerated Measurements
The process for creating and editing an Enumerated Measurement is similar to that of a standard Measurement. Below are detailed the differences.
Measurement System
The Measurement System is automatically set to "AbstractDiscreteSetMeasurementSystem".
Enumerated Measurement Axis
The user needs to create a new Enumerated Measurement Axis. This new Measurement Axis has an extra field: LDM Measurement Labels.
An Enumerated Measurement Axis must have a Value Type Unit. Selecting a Value Type and a Constraint add the measurement labels specified by the Constraint and populate the list of existing labels with the remaining ones from the Value Type.
The user can add either a new label or an existing one from the list. If a new label is added with the same name as an existing label, a dialog will pop up warning that a name collision has been detected.
A label can be reordered by dragging and dropping its row to a different position.
If the user doesn't specify a Value Type and/or a Constraint, they will be automatically created upon save using the list of labels the user added.
Enumerations
There are two general approaches to creating an Enumeration.
If you are making a "standalone" enumeration, you can simply create a VTU each time. In practice, we tend to do this more when we can creating enumerations for observables that typically have numbers. For example, we might do this for position if we wanted to represent HERE and NOT_HERE.
In the other case, you may wish to "share" your enumeration literals. How many different definitions of ON, OFF , and STAND_BY do you need? Considering that some systems do not have STAND_BY - don't ON and OFF still carry the same semantic? In this case, you may wish to have a share a VTU that defines these enumerations and then use an Enumeration Constraint to choose the subset of enumerations that you wish to include.
Platform Type and Enumeration
Accessing Platform Types
Platform Types can either be accessed by double-clicking them in the NavTree:
Or they can be accessed by clicking the link in the 'Platform Type' field of View Attributes using them:
Platform Type Creation/Editing
Platform Types can be created by either selecting the corresponding option in the Create > Platform dropdown menu:
Or by clicking the "Create Platform Type" button in the View Attribute page.
The difference between creating/editing a Platform Type from either location is that the "Realized Abstract Measurement" will be inferred from the View Characteristics while on that page whereas it will need to be filled in by the user on the dedicated page. On both pages, the user will also need to fill in a unique name, a Primitive Type, and a Constraint. If there is no appropriate Constraint listed in the dropdown, the user can create a new one.
Enumeration Platform Type Creation/Editing
Selecting "Enumeration" as the Primitive Type makes extra fields appear for the user to add Enumeration Literals.
To add a new Literal, click the "Create" button at the bottom left of the Platform Literals table. New Literals, not yet saved, will appear in green. Literals must have a valid FACE-Conformant name.
Existing Literals will appear with a white background. Both the Enumeration and its existing Literals can be edited by changing their Name fields. Any new Literal will lose its green background once the user clicks the "Save" button in the upper right corner:
Clicking the 'X' in the Delete column will mark the Literal for deletion. You can mark Literals for deletion even if they have not yet been saved. Literals marked for deletion will have a red background. The Delete button will change to a checkmark, toggling this will un-mark the Literal for deletion:
Realizing LDM Measurement Labels
To the right of the Platform Literals table is the LDM Measurement Labels. These Labels are traced through the Measurement the Enumeration realizes.
On each Literal, the drop-down in the "Realizes" column will show unrealized Labels from the LDM Measurement Labels table:
After choosing an item, the drop-down for subsequent Literals will show remaining Labels:
When selecting the "Realizes" drop-down for a Literal that already had "Realizes" set, selecting the empty row at the top will remove the "Realizes" relationship:
The "Add Matches" button next to the "Create" button under the Platform Literals table can automate some common editing/matching done from this editor. Clicking it will:
- Assign the "Realizes" relationship to all Literals that are unmatched, and have a direct name match with an unrealized LDM Measurement Label.
- Any Labels that are not realized after assigning matches will have new rows added to the table.
To see this in action, let's see what happens when "Add Matches" is clicked in the below scenario:
The "ACTIVE" Literal had a direct match with the "ACTIVE" Label and as such was set to realize it. Subsequent unrealized labels had their own rows injected. At this point, more edits can be made (naming, changing realizes, even deleting the new rows added), or the changes can be saved by clicking the "SAVE" button in the upper right corner.
Constraint
Constrains limit the possible values of a view attribute to which they are applied. The nature of the constraint is based on the primitive type employed by the view attribute.
Creating a Constraint
A new Constraint can be created by selecting the corresponding option in the 'Create>Logical' dropdown. Please note that, at this time, the editing of existing constraints is NOT supported in PHENOM - once created a constraint may only be viewed by selecting it in the NavTree.
A constraint can be one of three types: Regular Expression, Real Range, or Integer Range.
Much like the name suggests, a Regular Expression Constraint requires an expression which will limit the possible string values of a view field.
A Real Range Constraint has a lower and an upper bound, and can also specify the exclusivity of each.
An Integer Range Constraint limits the input between a lower and an upper bound, both of which are exclusive.
Applying Constraints to Platform Types
When creating or editing a Platform Type, you may associate a constraint with it. The primitive must be selected before a constraint can be applied - the constraints options will be filtered based on the primitive that has been selected.
String and Char primitives can have a Regular Expression constraint applied to them. Float and Double primitives can have a Real Range constraint applied to them. All other primitives are limited to Integer Range constraints. Enumerations cannot have a constraint applied to them at this time.
A new constraint can also be created while on the view attribute page by clicking the 'Create New Constraint' link on the right side of the constraint selection section. The creation form in the dialog will be limited to the constraint type that is applicable to the already selected primitive.
Measurement System and Coordinate System
Creating & Editing Measurement System
To create a Measurement System, select the option from the Create > Logical dropdown menu:
Measurement Systems can either be regular or Standard. The process to create/edit the two types is slightly different.
Measurement System
There are a few requirements to create a Measurement System, it needs to have:
- A unique name
- A Coordinate System
- At least one Measurement System Axis
The user can select a Coordinate System from the list. Information about the selected Coordinate System will be displayed below the list. Clicking on "Select Coordinate System" collapses/expands the list.
The user can select one or more Measurement System Axes from the list. Information about the selected Measurement System Axes will be displayed below the list. To unselect a Measurement System Axis, the user needs to click again on it, it won't be highlighted and its information box will be removed. Clicking on "Select Existing Measurement System Axis" collapses/expands the list. The user can also create new Measurement System Axes, this is explained below
After the Measurement System is created, the user will be able to create Reference Points and see the ones already added.
The Conversions section is not editable. Once the Measurement System is created, the table will be filled with Conversions which source or target is the selected Measurement System.
Standard Measurement System
There are a few requirements to create a Standard Measurement System, it needs to have:
- A unique name
- A Reference Standard
Creating & Editing Measurement System Axis
To create a Measurement System Axis, select the option from the Create > Logical dropdown menu:
There are a few requirements to create a Measurement System Axis, it needs to have:
- A unique name
- A Coordinate System Axis
- At least one Value Type Unit
The user can select a Coordinate System Axis from the list. Information about the selected Coordinate System Axis will be displayed below the list. Clicking on "Select Coordinate System Axis" collapses/expands the list.
The user can add one or more Valut Type Unit(s). Clicking "Add Value Type Unit" will add a creation form.
If the user doesn't find the correct constraint, she/he can add one by clicking the "Add Constraint" button. This will open a Constraint creation form. After the Constraint is created, it will be added to other Value Type Unit Constraint's dropdown list.
Creating & Editing Coordinate System
To create a Coordinate System, select the option from the Create > Logical dropdown menu:
There are a few requirements to create a Coordinate System, it needs to have:
- A unique name
- A Coordinate System Axis
The user can select a Coordinate System Axis from the list. Information about the selected Coordinate System Axis will be displayed below the list. Clicking on "Select Coordinate System Axis" collapses/expands the list.
The Conversions section is not editable. Once the Coordinate System is created, the table will be filled with Conversions which source or target is the selected Coordinate System.
Creating & Editing Coordinate System Axis
To create a Coordinate System Axis, select the option from the Create > Logical dropdown menu:
The only requirement to create a Measurement System Axis is a unique name.
Reference Point
Creating & Editing Reference Point
To create a Reference Point, navigate to a Measurement System page and click on the "Add Reference Point" button:
This will redirect the user to the Reference Point Editor. The user can go back by clicking "Back to parent Measurement System".
There are a few requirements to create a Reference Point, it needs to have:
- A unique name
- A Landmark
The user can select a Landmark from the list. Information about the selected Landmark will be displayed below the list. Clicking on "Select Landmark " collapses/expands the list.
The user can add one or more Reference Point Part(s) by clicking the corresponding button.
Creating & Editing Reference Point Part
To create a Reference Point, the "Add Reference Point Part" button in the Reference Point page:
There are a few requirements to create a Reference Point, it needs to have:
- A value
- A Measurement System Axis
The list of available Measurement System Axes is filtered depending on the Measurement System, the Reference Point will be included in.
The user can add a Value Type Unit by clicking "Add Value Type Unit". Clicking the x icon next to the Value Type Unit will remove it. If the user doesn't find the correct constraint, she/he can add one by clicking the "Add Constraint" button. This will open a Constraint creation form. After the Constraint is created, it will be added to other Value Type Unit Constraint's dropdown list.
Diagram
Diagrams are a useful tools for visualizing and exploring your project. They demonstrate visual connectivity and relationships including associations, compositions and semantic paths. For convenience, they can be saved and exported for future re-use.
Diagram interface overview
Interface overview
The Diagram interface is composed of 5 parts:
- Main top menu for the most used features of diagrams
- Stencils for creating new diagram content
- Details and Usages panels on the right
- The center canvas to visualize and arrange diagram content
- The NavTree on the far left
General menu actions
The first set of actions in the menu allows:
- Clear Diagram: Removes all objects from the canvas
- Auto layout: Rearranges all objects on the canvas
- Zoom: Custom zoom levels for the canvas area
Interface modes
A diagram can be used in one of two modes (1) Modeling (2) Projection:
Modeling mode
This is the standard entity diagramming mode that allows for the editing of entities and associations. This includes the creation of composition and association relationships.
In modeling mode, the projection connectors are hidden.
Projection mode
This mode is specifically designed for the creation and editing of Views. This includes the creation, editing and displaying of the semantic projection paths making up that View.
In projection mode, the modeling connectors are hidden.
Managing elements on a Diagram
Adding elements to the diagram
Elements can be added to the diagram canvas from different locations:
- From the stencil panel: Dragging an object from the stencil panel will create new entities, associations, and views. These elements are not committed to any model, but can be found in the NavTree under the UncommittedEntities package.
- From the NavTree: Dragging an existing object from the Navtree will add those objects to the diagram canvas where they can be directly edited and saved within the diagram.
To create a composition, click and drag the 
icon to another object.
To create an association, click and drag the 
icon to another object.
Note: An Association must have at least 2 connections to be valid.
Interacting with elements on the diagram
Most components on the diagram have a right-click contextual menu allowing the user to interact with them.
Below is a table detailing how mouse clicks interact with the elements on the diagram.
| Menu Item | Action |
|---|---|
| Edit | User can add/edit/hide/remove the node's attributes |
| Remove | Remove's the node from the diagram. The removed node will continue to persist in the model. |
| Reveal in tree | Finds the node in the Nav Tree. |
| Show all attributes | To reduce on-screen clutter, the user can choose to hide specific attributes. "Show all attributes" will reveal all hidden attributes. |
| Hide types | To reduce on-screen clutter, the user can choose to the attributes' type. |
| Show usage | This will open the Usage side panel and display the node's referencers and referencees. |
When hovering over an entity, a tooltip displays its description.
When an entity or an association is selected, the right-side panel can display its details and usages:
- Details: Displays editable Name and Description fields for the entity.
- Usage: Displays usages of and relationships to that object throughout the rest of the model including Compositions, Associations, Specializations and Views.
Deleting and removing elements
The option to "Remove" exists for all diagram objects. This means that they are removed from the diagram but they still exist in the model or in the UncommittedEntities list.
An option located in the Gear menu on the far right of the menu bar allows the user to switch off the Delete/Remove confirmation messages for convenience.
Diagram management
There are 5 actions that can be performed on a diagram:
- Load: Allows the loading of a saved diagram and also the ability to delete saved diagrams.
- Save: Saves the current diagram. Everything that is displayed on the diagram (committed entities, uncommitted entities, connections, drawings...) will be saved in the diagram.
- Save As: Saves the current diagram as a new file.
- Export: Exports the diagram as a PNG image
- Commit: Commits the changes to the model and auto saves the diagram.
Note: if a diagram is not saved, then all changes made to it will be lost when the page is refreshed
Load Diagram
In the NavTree, double click the diagram node to load the diagram.
Committed and uncommitted entities
Uncommitted entities
Uncommitted entities are created by dragging an Entity, Association or View block from the stencil panel. Once on the diagram canvas, they can also be found in the NavTree under the UncommittedEntities package.
Note: If uncommitted entity is not saved in a diagram or committed, when the diagram page is refreshed, they are lost.
An uncommitted entity can be reused in all the diagrams that the user has open, but in order to be used within a View path, they must be committed first.
Commit entities
When an entity is created or updated from the diagram, the changes are not stored in any model until the user commits them.
When the user clicks the "Commit" button, a dialog appears listing all the entities that have been created or updated. The user can chose to commit all or some of them to a specific model.
Note: If a diagram was saved with uncommitted entities, when they are committed, the diagram is re-saved to account for the change and keep the data synchronized.
Building view paths
To build, a new path for a view:
- Add a new field to a view. The rolename can be added later and the measurement will be added automatically when the path is built.
- Select the 1st hop in the path which will be either an entity or a path. The available elements are highlighted in green
Steps to create a path
1. Select the Projected Characteristic. The selectable entities and associations are highlighted in green.
2. Select the next hop. The possible subsequent hops are highlighted in green. They are either an attribute within the current hop selected or within associations that contain the current hop.
3. To complete the path, the last hop have to be typed as an Observable.
Paths can be shown/hidden using the 
icon. By using the show/hide eye icon repeatedly, the View paths will randomly change colors for convenience.
Healthcheck
Running a Project Healthcheck
There are certain characteristics that make some projects more useful than others. Projects defined using a clear, unambiguous structure are very well suited for automating integration. Their structure aligns them well for determining semantic equivalence with other systems. Some of these project qualities can be checked running relatively simple algorithms while others are far more complex. As additional project healthchecks are added to PHENOM, they can be run from this control panel.
To get to the healthchecks, navigate to the Data Model mode and select the Healthcheck tab. This will present you with a blank healthcheck page. Click on the "Run Healthcheck" button to initiate the tests. Please note, the tests may take a few minutes - a spinner icon indicates that PHENOM is working.
Once the tests are complete, the user will be presented with a summary of the test results. The summary will show the number of tests executed, the total number of issues found in the project, and the amount of time it took to complete the checks. In the middle, the summary reports the individual tests executed along with their results. In the example below, most of the entities in the project are unique, but there are many that do not have unique observables. There is a complete, color-coded listing of all the violations on the right-hand side of the page. This provide details about the errors to help identify and fix specific them in the project.
All test results can be downloaded as a CSV file by clicking on the "Download Report" button.
The project can be filtered by tags and be used in Healthcheck but please be aware that the healthcheck will ensure the project is a valid project. So if a set of nodes are excluded but they have dependencies, then the Healthcheck will add the nodes back in and they will appear in the health report.
Healthchecks
Entity Uniqueness
The Entity Uniqueness check determines if all of the entities in the project have a unique set of attributes and associations. Theoretically, if two things have the exact same set of attributes, then they are the same thing. While it may not seem to have any short-term consequences, entity uniqueness will be much more important when projects are analyzed for similarity and merge.
Attribute Uniqueness
Attribute Uniqueness checks to make sure that all entities have a set of unique attributes - that is, no two of its attributes can be of the same Entity type. How many positions does a vehicle have at once? Only one!
While that position may be measured a number of different ways, the truth is, that entity only has a single position.
Furthermore, when there are multiple attributes of the same type within an entity, the only way to discern any difference is by reading the attribute labels. These labels can be as misleading as they can be informative. Just like documentation in ICDs, sometimes a word choice that is clear to one person may be entirely ambiguous to another.
Observable Uniqueness
Similar to 'Attribute Uniqueness', Observable Uniqueness checks to make sure that all entities have a set of unique attributes - that is, no two of its attributes can be of the same Observable type. How many positions does a vehicle have at once? Only one!
While that position may be measured a number of different ways, the truth is, that entity only has a single position.
Furthermore, when there are multiple attributes of the same type within an entity, the only way to discern any difference is by reading the attribute labels. These labels can be as misleading as they can be informative. Just like documentation in ICDs, sometimes a word choice that is clear to one person may be entirely ambiguous to another.
Name Collisions
Although PHENOM will generally not allow users to create node with a name that is already in the project, there are ways in which name collisions may occur, including merging between branches or importing project content from external sources. Regardless of how they came about, any problematic name collisions (name collisions between nodes of the same type or having the same parent) will be reported here.
Circular Containment
While there are some legitimate cases for circular containment between entities and associations, a large number of these will be caused by modeling oversights. Such containments, as when entity A composes entity B, which in turn composes entity C, but entity C itself composes entity A, will be reported here.
Path Traceability
Although PHENOM's path builder ensures that only valid paths can be constructed, legacy paths from old imports may still find their way into a PHENOM project. Paths that cannot be legitimately traced through the project will be reported here. They will also be indicated with warnings on the View and View Attribute pages.
Placeholder Usage
In order to speed up modeling, PHENOM makes available a suite of placeholder nodes, including an observable, entities, and measurements. While the use of placeholders is convenient, projects containing placeholder values are not compliant. Four placeholder checks are part of the health report, indicating which view attribute paths contain placeholder entities, which paths project the placeholder observable, which entities type the placeholder observable, and which view attributes use a placeholder measurement.
Entities without an Identifier
Phenom encourages the addition of an Identifier attribute on every Entity (see the "Add Identifier attribute" checkbox on Create->Entity), to uniquely identify one Entity from the rest. While Entity uniqueness checks that each Entity has a unique set of Types, Entities without an Identifier checks that each Entity is Identifiable.
Deprecation Issues
Deprecating a node can affect other nodes either through paths or realizations. This section will report which nodes have been effected by deprecation and give an option to fix them. To fix deprecation issues, click on the wrench icon to bring up the UI. Currently, there are two different fixes available:
- Fixing composition types.
- Fixing path issues (for View Characteristics and Associated Entities)
Compositions Referencing Errors
Compositions that realize a deprecated observable will appear in this section.
Each composition is referencing the current deprecated Observable. A new observable can be selected from the dropdown list. By clicking SAVE, each composition will be updated with the new observable. * If a composition should not be updated at this time, you can deselect it by clicking the checkmark. * If a composition is highlighted, this means there is another layer of references to consider.
By changing the composition's observable, then the referencing view characteristic's measurement will need to change as well. In the top left, you will see the Current Measurement that each characteristic is pointing to. You can either set all of the measurements at once or you can set each measurement individually.'
Paths Errors
Both View Characteristics and Associated Entities may have path issues caused by deprecation. Each of these categories have their own section.
In the above example we have three different view characteristics called vsm_ID. Each of these have the same path that contain a deprecated node (UCSConfigurationResource). After creating a new path, click SAVE to update the path for each view characteristic. However if a characteristic should not be updated, you can deselect it by clicking the checkbox and fix it at a later time.
To see more about the Path builder, please see View Attribute.
Platform Enumerations with improperly matched Literals
This healthcheck captures issues with Platform Enumerations that don't match their realized Measurements, when comparing their Platform Enumeration Literals to the Measurement's Labels.
There are two categories that can currently show up on this report:
- 'Missing-realize': Enumerations will be marked as this if any of the PDM Literals do not have a 'REALIZES' relationship, or are realizing a Label with a different name.
- 'Mismatched': Enumerations will be marked as this if there aren't direct name matches between any of the PDM Literals and the Enumeration's traced LDM Labels, or if there are duplicate names.
These issues may not always indicate a problem with the Enumeration; there will be scenarios where a modeler may want to have specialized names in the Platform-level Enumeration that differ from the LDM Measurement Labels. Setting the realize relationship on LDM Literals indicates which Label a Literal represents.
Clicking on the links of each Enumeration found in this healthcheck will bring up the Platform Type editor, which you can use to manage them. For more details, go to Platform Type and Enumeration.
To see the Project Generation behavior PHENOM follows when generating Enumeration content, please see: Model & Artifact Generation
Views without Characteristics
This healthcheck captures Views without any child Characteristics. Platform Views are exported from Phenom as Views in FACE 2.1 and Templates/Queries in FACE 3.0. In both standards, the resultant element must not be empty.
Specialization Inconsistencies
Specialization Inconsistencies checks for inconsistencies in specializing Entities. Phenom's representation of specialization requires consistency in the attributes between the Entity specializing, and the Entity being specialized. If any of the attributes being specialized in Entity A are not present in Entity B, they will be present in this healthcheck.
FACE™ SDM Conformance
Use this healthcheck to monitor model conformance. As new versions of the FACE SDM are released, they will be enumerated in this healthcheck. Green check marks indicate matching conformance, yellow warning signs indicate disparities in expected SDM node content, and red X's indicate that content referenced by an SDM node could not be found in your model.
Platform Types with inappropriate type or Measurement
This check finds any discrepancies in Measurement realization. Among the following Platform Types Phenom supports, ("Boolean", "BoundedString", "Char", "CharArray", "Double", "Fixed", "Float", "IDLArray", "IDLSequence", "Long", "LongDouble", "LongLong", "Octet", "Short", "String", "ULong", "ULongLong", "UShort"), there are two additional supported types that are mutually exclusive with the previous list, to the measurements they can respectively realize: "IDLStruct", and "Enumeration". IDLStructs can only realize Measurements with multiple axes, and Enumerations can only realize Enumeration Measurements. All other types above cannot realize multi-axis or Enumeration Measurements.
Optional Characteristics
This check reports any characteristics marked "optional" in Phenom. Use this report to manage any characteristics marked this way.
Integration Context
If there are any issues with Integration Model content, those issues will be reported here. This includes checks for issues such as inconsistent data types, missing message ports, and endpoints with multiple connections.
Conversion Errors
Of the logical conversion elements Phenom supports, ("MeasurementConversion", "MeasurementSystemConversion", "CoordinateSystemConversion"), if any contain an invalid equation, Phenom will report these here.
Bounds Issues
There are many elements Phenom supports that may have lower or upper bounds. Of these elements, if any have invalid bounds, (for example - lower bound is greater than upper bound), Phenom will report these elements here.
Nested View Issues
This health check finds all privately scoped nested views used in more than one perspective or used within more than one view family.
Composed Block Instance Issues
This health check traces through the node connection and compares the Composed Block Instance with the connected block node, and searches for mismatched data types or inconsistent template types.
Meridian Map
Using the Meridian Map
To access the Meridian Map, go to the Data Model mode and click the Meridian Map tab.
After selecting the views the user is interesting in, to add them to the map, the user can:
- Drag them over the map and drop them when a green checkmark appears. The views can be added either one at a time or multiple at one.
- Click the Refresh button. This will replace any existing views previously added to the map with the newly selected ones.
Anatomy of the Meridian Map
The Meridian Map contains three crucial pieces of information.
The teal line around the outside of the Meridian Map represents the View. In some cases, this may be considered a software interface or even a message. Mousing over the arc will display the name of the corresponding view.
The smaller squares that line the inside of the Meridian Map represent the attributes of the views. Ultimately, the attributes are the most important elements to map to other views. Views, in their entirety, are not expected to map. Mousing over each square will display the name of the view and its attribute.
Finally, the heart of the Meridian Map shows the connectivity between two (or more) attributes. When multiple views are added to the diagram, their semantics are compared and matched. An arc is drawn for each of the attributes with matching semantics and the semantic description (the concept to which that attribute corresponds) is displayed when hovering it.
A semantic arc can be blue or red:
- Blue indicates Semantic Match
- Red indicates Semantic Match with same Measurement
Blue will match Latitude <-> Longitude (because, conceptually, they are both position). However, Red will further distinguish based on their measurements (i.e., it uses semantics + measurements) If the user checks the "Logical Matches Only" box located in the top right corner, only red arcs will be displayed.
When a semantic connections band is selected, more detailed information about that match is rendered in a small table below the Meridian Map.
When an attribute is selected, all of its semantic matches are rendered in the same table. If there is more than one match, all will be rendered in the right-hand column.
Semantic Matches
Purpose of Semantic Matching
When creating a View Attribute, which is meant to represent a piece of data about a system, PHENOM allows users to create a path which associates with the view attribute to document the meaning of the contained data. This path is written in terms of Entities, Associations, Observables, and the relationships between them and constructed in the conceptual layer (CDM) of the Domain Specific Data Model (DSDM). (For a more detailed review of creating a path using PHENOM, refer to the View Attributes page. For a more thorough discussion of how meaning is imbued in view attribute paths and the rational behind their construction, review the interface documentation tutorial.) When the paths of two different view attributes are identical (or at least similar), the implication becomes that the data contained within them represents the same thing. Even if view attributes represent data measured in different units or against different coordinate systems, or sent using different primitive values, because the paths in PHENOM are documented in terms of conceptual level entities, we can determine when the meaning of the data is identical even if a transformation may have to be performed to reconcile the differences on the logical and/or platform levels.
The semantic match dialog in PHENOM lists perfect and approximate semantic matches of a given view attribute and gives a relative evaluation of match strength:
- Above the table headers, the user can see the characteristics of the selected View Attribute
- A filter box to filter the View column
- Each match and its attributes show up as clickable links sorted by match strength
Viewing Semantic Matches
There are two places in PHENOM where the semantic match dialog can be accessed. The first is a View's details page. Each row of a view's attributes table contains a "Show" link in the "Semantic Matches" column. Clicking this link will bring up the semantic matches dialog.
The second is the View Trace page. After a view has been added to the diagram, clicking on an attribute's name will bring up the semantic matches dialog.
Use of Semantic Matches in PHENOM
Semantic matches are the basis for drawing the connecting bands between view attributes on the Meridian Map. Perfect semantic matches are also what is used to automatically determine mappings between attributes of different views in the View Trace, though partial matches can be manually reviewed to create mapping of attributes with only similar paths.
View Trace
Using the View Trace
To access the Meridian Map, go to the Data Model mode and click the View Trace tab.
Drag and drop 2 views into the red and blue areas. They must be on opposite 'teams' to enable the mapping between them.
Right-click on a view and select "Trace all attributes" to display all the semantic matches between the views' attributes. Note that the colors don't have any meaning, they just allow better differentiation between the clusters of matchings.
Click the "Clear Nubs" button to clean up items that don't have a match on the other side.
ADD IMAGE
The View Trace works like the main Diagram tool. As such, the user can
- Create multiple View Trace diagrams by clicking the + icons next to the last diagram tab
- Save the View Trace
- Load a save View Trace
- Export the View Trace as a png image
Semantic Matches
As described in the Semantic Matches page, to display the Semantic Matches for a specific View Characteristic, click on it.
Preferred Mappings
To capture a custom mapping, drag the mouse from the left-side attribute's type to the right-side attribute that should match. A dotted-line arrow will be displayed indicating the custom mapping.
In the top menu, the "Mappings" toggle allows the user to display or hide the custom mappings.
Right-clicking on a preferred mapping the user can:
- Remove the mapping: this will remove the mapping from the diagram but not delete it. To make it reappear, click twice the "Mappings" toggle
- Delete the mapping: this will permanently delete the mapping.
Import
Within Data Model, the Import tab is where users can bulk import data into PHENOM. Model import using a .face file is available from the Projects and Models Management page.
Users can bulk import data into PHENOM using a properly formatted CSV file. The types of data the user can import are:
- View-Characteristic
- Enum-Literal
- Model-Content
- Constraints
- Platform Types
Phenom can add a set of placeholder model elements to help you in your modeling efforts. These model elements will be most useful when you are not completely sure what observable or entity best represents the semantic you are trying to document or what measurement best represents the one used by a particular interface. In these instances, you will be able to use or project to a placeholder, coming back later to revise your project.
The placeholders will include an Observable, a Measurement System, commonly used Measurements, and a placeholder entity.
Example
In this example we are using the AcccelerationPlaceholderMeasurement.
When we're ready to revise the project, the placeholder usage will appear in the health check.
Merge external model will inject nodes from a provided model file into the current project. If Overwrite is enabled, nodes that are present in both the source and the destination project but are different in the destination project will be edited to resemble the ones in the source model.
Analytics
The Analytics tab provides tools to summarize different aspects of your model and review and compare large sets of model nodes.
Entity Usage
The Entity Usage tool provides an at-a-glance overview of entities most commonly used in project paths as well as an overview of how many entities remain unused. Hover over the graph to see the name of the entity presented and the exact number of times it is used.
Attribute Usage
The Attribute Usage tool provides an at-a-glance overview of attributes most commonly used in project paths as well as an overview of how many attributes remain unused. Hover over the graph to see the name of the attribute presented and the exact number of times it is used.
Semantic Equivalencies
The Semantic Equivalencies tool allows you to determine the percentage of characteristics in a group of views that have semantically equivalent paths within another group of views.
Integration Modeling
The details tab is where most of the detailed model editing is done. Although selecting the details tab directly does very little, this is where the properties appear once an element has been selected from the NavTree.
The Integration Model editor allows the user to create and update Integration Models and explore their connectivity similarly to the Data Model Diagram. This users are able to draft integration model content without immediately affecting the Data Model. This makes it possible to experiment with different modeling ideas without adding a bunch of intermediate content to the model. The new elements become official model content once they are "committed."
Integration Model Details
From the Details tab, users can review detailed information about model nodes, create new nodes, and edit or delete existing nodes. Not all of types of nodes can be created, edited, or deleted, and there are some nodes which will not appear in this user interface. The nodes accessible through the details tab and their available user interactions are summarized below. Note that from anywhere in PHENOM, if the user double clicks on a node, she/he will be redirected to the details page of the selected node.
Page format
All details pages are built in the same way:
- All the action buttons (Save, Reset, Delete) are located in the sub-tab bar in the top right corner.
- The top right corner of the page provides indications about
- When the element was last modified and by whom
- The model the element belongs to
- The Changeset selected
Most details pages also allow the user to edit/view the tags applied to the element
PHENOM's Packages function like folders that help users organize components of the project as well as their own files and content.
Both Service / UOP nodes and the message port nodes that comprise them can be viewed and edited within PHENOM.
Transport Channel is a placeholder for an integrator supplied configuration between transport endpoints.
Service / UOP & Message Port
To create a Service, select the corresponding option from the Create > Integration dropdown menu.
Once on the page, the user can edit the name, description, partition type, and profile of the node as well as add or remove any appropriate tags. The user can also add new Message and Life Cycle Management Ports.
New Message Ports can be created by clicking the "Add New Message Port" button below the Message Ports list. New and existing Message Ports can be editing in line.
A Message Port must have:
- A unique name
- A Message Type
- A Period
Existing Message Ports are collapsed by default for compactness. Each row can be expanded by clicking the > icon. A Message Port can be removed by clicking the trashcan icon.
Transport Channel
Transport Channel is a placeholder for an integrator-supplied configuration between transport endpoints.
To create a Transport Channel, select the corresponding option in the Create > Integration dropdown menu.
A Transport Channel must have one of three types: multicast-UDP, DDS, AMQP. Note that no matter the type, commas (,) are not allowed in input fields.
Multicast-UDP
TTL accepts a number between 1-255.
DDS
Domain Participant Id accepts numeric characters. The other input fields accept alpha-numeric values.
AMQP
Integration Model Editor
The Integration Model (IM) Editor is a groundbreaking new region of PHENOM that combines visualizations with direct model editing.
The Integration Model is perhaps the most important model of them all. It provides a representation of how your UoPs and communication channels are laid out in the physical world.
A well-designed IM is what allows us to generate a fully configured CinC transport layer.
UoP Instances
UoP Instances are, as the name suggests, instantiated Units of Portability. They can be created from the IM Editor or from the 'Create' dropdown in regular Navigate mode.
Each one is given a name and a Configuration URI (optional). You are also expected to select some subset of the UoP's Connections to use as Endpoints in the UoP Instance.
Transport Channels
A Transport Channel holds information required to transmit across some outside channel.
Currently UDP channels are supported.
At the moment, you are expected to use the description field to populate the following comma-separated values: ip, local port, destination ip, destination port, ttl.
Integration Contexts
This is where we find the real meat and potatoes of your integration situation. A Context is a graph representing the flow of DataTypes, or Views, amongst UoP Instances.
A given context can pull in the items discussed above. In fact, a given UoP Instance might be used in multiple Contexts. The different Contexts simply illustrate different aspects of the layout.
The IM Editor lets you work on one Context at a time. First, drag and drop to insert a UoP Instance. (Technically, the UoP Instance exists outside the Context, but since it's connected to things inside, it will be useful to have it here).
Processing Blocks
Processing blocks come in several flavors which can be created by dragging and dropping from the Stencil tool on the left-hand side.
Once placed in the Context, the Block Inspector on the right-hand side is used to give the blocks names, descriptions, and other data specific to its type.
- Sources / Sinks have only one port. These represent elements that simply produce or consume Views.
- Transforms consume one type of View and produce another. The Block Inspector is used to adjust settings. Notably, the Transform type is used to change from
- Automatic transform that draws on semantic and measurement information to mediate between the two Views:
- Manual transform, which allows arbitrary assignment fields which will be parsed and incorporated into the generated transformation code:
- Filters require a 'Test' field that will filter out Views for which the test evaluates to False.
- Transporters allow you to select a Transport Channel to transmit across.
- FanIns allow for several input connections and only outputs one type.
- Generics can have any number of input or output connections.
- SIM Adapters for Single Instance Messaging communication style.
- Queuing Adapters for Queuing communication style.
- Data Pumps periodically poll the previous block to move messages forward.
The Adapter blocks allow interoperability when the UoP Message Port is expecting a certain kind of communication style.
Connections
Connections are created by dragging from an output port to an input port:
If the data types are inconsistent then the connection will turn red and you won't be allowed to save. In this situation, we have a UoP Instance block outputting BasicTypes, and sending it to an Endpoint expecting ComplexTypes:
Ports
Ports facilitate the type that is used during context block connections and can be either input or output endpoints. Ports can accessed from the Block Inspector on the right-hand side when selecting a block with ports. All ports have rolename, flowtrigger, type, and a special identifier field depending on which type is selected. Additionally, ports can be dragged around a context blocks border from within the context.
There are two types of ports:
a) Data Type
Data Type must be given from an existing view type from the model.
b) Template type
Template type is determined by the user.
Composed Block Integration Contexts
The composed block integration context is a special kind of context that can be nested inside another context of any type, treating it as a context block via a composed block instance.
Any high-level context can include a composed block instance to simplify complex modeling and connections. This setup lets viewers understand the overall flow without getting overwhelmed by the modeling details held within the composed block context.
Switching an Integration Context to Composed
A context can be switched from normal to composed from the context tab from within the side panel. Once switched, the context will behave just like a normal context but obtain a blue border and allow access to the composed ports.
Composed Ports
From within the composed block context, the user may drag in any number of Composed In/Out port blocks. The composed ports blocks have only one respective input/output port and can be connected to the other context blocks. They need to be configured similarly to normal ports and require a Type and designated identifier (DataType or TemplateType).
These composed port blocks are identical to the ones utilized by a composed block instance.
Composed Block Context Instances
After the user is finished creating their composed block context and either saves or commits it, the composed block context can be seen in the NavTree and is ready to be dragged in as an instance to another context of any type.
Once dragged in, it behaves like the other context blocks and can be connected to any of the other blocks and even other composed block context instances. The ports represent the composed ports modeled in the actual composed block context.
Generate
Generate is where use can create models for export and FACE-aligned Transport Service software.
This area is used for generating different products from the data model. The types of products that can be created are:
- Data Models (FACE XMI format)
- Archive of all User-created Diagrams (PNG format archived in a ZIP file)
- Interface Description Language files (IDL format)
- Skayl's Proprietary Format (Similar to FACE XMI, but this preserves the non-standardized integration model content)
- User Template
CinC is Skayl's Configurable Infrastructure Capability. This is a fully configured FACE Transport Service that can be easily configured in PHENOM. This tab contains all the controls needed to export FACE-aligned software. Two types of products can be created:
- FACE 3 CinC
- FACE 3 Mock UoPs
PHENOM allows users to build their own templates for exporting data. Users are able to access numerous data model elements and format them per these templates. The template language is Apache FreeMarker and PHENOM provides several sample templates to help users get started.
==Data Model Generation==PHENOM can generate a number of different data model formats and documentation artifacts from the current project.
Filter
The first drop down in the page allows the user to filter the nodes in the model and the Nav Tree to only that will be used for generation.
- None: no filter is applied
- Services: only display the services in the Nav Tree and only services will be exported (along with any elements necessary to export a valid model)
- Views: only display the views in the Nav Tree and only views will be exported (along with any elements necessary to export a valid model)
- Tags: the tag filter currently applied in the Nav Tree will be applied to the model upon export (necessary elements to make the model valid will be exported as well)
Generate Models & Artifacts
The user can then choose the type of artifact to generate. Each type of artifacts has its own generation parameters.
FACE (.face)
This type exports a data model in FACE XMI format aligned with the FACE Technical Standard. The user has to choose which version of FACE to export the data model as. There is also the option of selecting additional export options via the checkboxes below export type and FACE version.
Diagrams (.png / .zip)
This option exports all the user-created diagrams and/or view traces as PGN files or in a ZIP archive if multiple are selected. Allows for the preview of diagram images with the preview and regenerate buttons.
IDL (.idl)
This option exports the data model in Interface Description Language (IDL) format.
Skayl (.skayl)
This option exports the data model in Skayl's Proprietary Format. This format is similar to FACE XMI, but it preserves all non-standardized content, including integration model content.
User Template
This option exports the data model using user templates. These templates can be edited in the Templates tab.
CinC Generation
CinC is Skayl's Configurable Infrastructure Capability. This is a fully configured FACE Transport Service that can be easily configured in PHENOM. This tab contains all the controls needed to export FACE-aligned software. Two types of products can be created.
FACE 3 CinC
This options generates a FACE 3.0 aligned CinC using the parameters provided by the user:
- CinC Version: version of CinC to use for the generation
- FACE Version: version of FACE used both for the FACE model export and the TS generation
- Language: language of the generated source code
- Override Namespace? / Namespace: by default, the generated code will use the top-level model name as namespace. If the checkbox is selected, the specified namespace will globally override the default values.
- System Directory: name of the folder where the dynamic CinC source will be generated
- Include CinC Source: whether or not the static CinC source files should be generated. If "None" is selected, only the files in the System directory will be generated
- Select your Mains and UoPs: selection of the Mains and the UoPs within the Mains to be generated
- CinC Licenses: a CinC license needs to be selected for each Main to generate
FACE 3 Mock UoPs
This options generates a FACE 3.0 aligned CinC with mock UoPs using the parameters provided by the user:
- CinC Version: version of CinC to use for the generation
- FACE Version: version of FACE used both for the FACE model export and the TS generation
- Language: language of the generated source code
- Override Namespace? / Namespace: by default, the generated code will use the top-level model name as namespace. If the checkbox is selected, the specified namespace will globally override the default values.
- System Directory: name of the folder where the dynamic CinC source will be generated
- Include CinC Source: whether or not the static CinC source files should be generated. If "None" is selected, only the files in the System directory will be generated
- Select your Mocked UoPs and Mains: selection of the UoPs to generate. For each UoP, the "Include main" option, if selected, will generate a mock Main for the mock UoP.
Templates
Templates allow users to define a custom format in which to extract data from their project, using Apache FreeMarker syntax. These can be used either directly from the editing page or in the Data Model tab of the Generate mode as a means to expand generation options beyond the defaults and help to support unique user requirements.
User Interface
Templates can be created, reviewed, and edited in the Templates tab of the Generate page. After editing a template, the user can:
- Save: saves a new template or any changes to an existing template.
- Clear: erases the content of the code window
- Reset: reverts all of the changes made when editing an existing template or erases any progress made when creating a new template
The Filter By dropdown at the bottom is used to filter the nodes that will be generated if the user wants to generate a model from this page using the selected template.
Template Syntax
Generally, templates are not used to extract or display data about a particular project node, but are rather used to format the reporting or indexing of a type or several types of node within the project. At some point in the template, a user will indicate what type or types of node will be used to fill in the contents of the file to be generated. The user will then be able to use a special syntax as placeholder for the data to be extracted from the project, surrounding the placeholders is any additional code necessary for the user's requirements.
Basic Template Syntax
PHENOM's templates use Apache FreeMarker, a full-featured template engine. You can reference their documentation for features that are not covered below.
To use a particular type of node to fill a template with data, declare the type and an alias for it in the following format: <#list type as alias></#list> Any code that go between the opening and closing list tags will be repeated for each node of the type, much like a loop iterating and writing out the contents of the list tag, each time using data from a new node of the requested type. The following code taken from logical_model.html (a default template) will create an HTML table with a header row followed by a row for each measurement found in the project. Note how the <#list> tags surround the tag, which means that code for a new table row will be generated for each measurement.
While the <#list> (ln. 11, 19) tags indicate a type of node to use and iterate over to generate code, the ${alias.attribute} (ln. 13 - 18) syntax is the placeholder which, at time of generation gets replaced with the value of the requested attribute of a particular node. Below is some HTML that the example template would generate.
Note how the attributes inside of the curly brackets get replaced with data particular to a measurement node (ln. 11-16) . Also note that the "..." in the code (ln. 18) indicates all of the rows which would have been generated for the other measurements in the project.
Iterating Over Child Nodes
Some nodes which can be used for generating templates may contain one or more child nodes or fields. A user can generate code for each one of these fields while iterating over the parent node by nesting list tags as follows:
<#list type as alias><#list alias.field as fieldAlias></#list><#list>
In this case, any code placed inside the internal <#list> tag would repeat for every field node of each type node. The code below (taken from view_comma_export.csv) is used to export data about each view field in the project:
Note that because calls like ${view.name} are placed inside the <#list> for the view field, this data will be repeated for each of the a given view's characteristic's rows.
Available Node Types / Attributes
The following tables summarizes all of the node types which can be referenced using template syntax, accessible attributes, as well as attributes of any possible field nodes.
| enums (Enumeration) | enums.fields (Enum Literals) | structs (IDLStructs) | structs.fields | views | views.fields | observables | units | measurements | constraints | entities | entities.attributes | uops | uop.fields |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| name | name | name | name | guid | guid | guid | guid | guid | guid | guid | guid | uop_name | port_name |
| description | description | modelName | xmitype | name | name | name | name | name | name | name | name | uop_desc | port_desc |
| measurement | type | description | type | description | description | description | description | description | description | pattern | |||
| measurement-guid | modelName | xmitype | realizes | type | specializes | type | message_request_type | ||||||
| observable | parent_view | description | measurement_system.name | upperBound | specializes | response_type | |||||||
| observable-guid | is_union | vector_type | measurement_system.description | lowerBound | synchronization | ||||||||
| fields | switch | bound | measurement_system.external_standards_reference | upperBoundInclusive | communication_style | ||||||||
| enum_switch | source | measurement_system.orientation | lowerBoundInclusive | period | |||||||||
| is_composite | path | measurement_system.coordinate_system | |||||||||||
| measurement | |||||||||||||
| type_model | |||||||||||||
| type_parent | |||||||||||||
| type_size | |||||||||||||
| c_type | |||||||||||||
| c_type_model | |||||||||||||
| c_type_parent | |||||||||||||
| source_name | |||||||||||||
| string_path | |||||||||||||
| is_foreign | |||||||||||||
| viewType | |||||||||||||
| optional | |||||||||||||
| union_cases | |||||||||||||
| imported | |||||||||||||
| c_imported | |||||||||||||
| switch |
Manage
Within Manage, the Branch tab is where users manage branching, including the ability to switch branches, pull changes from the parent branch, request to push changes to the parent branch, and approve push requests. Additionally, after initiating a push/pull request, users may create a Review Project, a snapshot of their project that allows for modification and review of the modeling content before finalizing the merge.
Before either pulling changes or approving a push request, users have the option to initiate a Review Project. This Review Project serves as a snapshot of the destination Project, incorporating the selected merge changes. Within the Review Project, users can find specific review pages within the Review tab to enhance the evaluation of review changes. After the review process is finished users may decide to finalize the merge and unlock the destination Project.
In some instances, a user may wish to share only a small part of a project with another user, without burdening them with the entirety of it. If the user you are sharing with only needs access to a few views or a subset of the measurements available, this functionality can be utilized to build a new filtered project that maintains its model inheritance relationship with the initial project. Any changes made to this new project can be pushed up to the initial project, and any changes made in the initial project can be pulled down to the filtered project so long as the changes are to a non-filtered element.
Within Manage, the Change Sets tab is where users can create or view a change set and its contents.
Permissions allow users to control who can see and edit project and model content.
Projects and Models Management
Projects & Models 101
A project in PHENOM is composed of one or more models which are loaded together into a workspace. A model is a collection of nodes. A node can be an entity, an association, an observable, a view… One objective of a project is to be:
- Independent
- Complete: reflect the reality to the best of its ability
- Compliant
- Valid (or at least "validatable ")
A model in and of itself might not constitute a complete, compliant, or even valid project as it might depend on entities inside other models, making it impossible to load independently. However, by combining several models in a project, they can form a complete, compliant, and valid model.
The following diagram depicts how a model can be part of multiple projects.
Once a project is loaded into PHENOM, the node contents of its constituent models can be added to as well as edited.
Projects Management
When in PHENOM > Manage Models > Projects, the user can see the projects and models they have access to.
The project you are currently working on is displayed at the top of all the pages. Additionally, in the Manage Projects page, the active project is the expanded by default and has a different icon.
To create a project, the user can click on the + button in the Projects list and then select existing models, import new FACE models, or add new blank models.
There are three ways a user can have access to a project or a model:
- The user creates it
- The user uploads it
- The user is assigned permissions from an external user
The user will see, for each model, its inheritors and versions.
The user can easily switch between projects in the Projects Management page.
Model Versions
In PHENOM, models maintain the content as well as the record of changes made to that content.
By default, each model has a "live" version. This is the version of the model which, when loaded in a project can be edited and amended.
When the user is satisfied with the current state of a model, they can publish it, thus creating a “static” version of that model. A published version of a model is a snapshot of its content at one point in time. It cannot be added to or edited but can still be included in a project, referenced by and depended upon by the contents of a different model.
In the example below, the model version FACE_SDM_306 and FACE_SDM_316 are a "published" version of the FACE_SDM model. While it can be shared with other users, included in a project, and referred to and depended upon by other models, it can never be edited. In the Model tree, all published models have their publication dates displayed for ease of use.
Model Inheritance & Content Merging
The same model can be loaded as a part of several different projects. However, the users of those projects will not be able to edit the content of the model simultaneously. When a user chooses to include in a project a model which is already a part of a different project, a "child" model will be created. This inheriting or "child" model is not a different version of a model, but rather its own model which inherits some portion of its content. At first, the inheriting and the parent models are identical but as their respective user make changes, they grow apart. Therefore, it’s possible for this "child" model to merge its changes to and from the parent model. A user can see the relationships between models in Manage Models > Projects > Model. In this example, the model Coffee is the parent of the model Coffee_in_Coffee_2. This results from the Coffee_live version of the Coffee model being loaded into a new project. When edits are made in either the parent or child model, the changes can be merged between them.
Clicking on a live or published model will display its characteristics on the right panel. The user will be able to edit some of the model's characteristics and the permissions of the model, provided the user has Admin or Owner privileges for that model.
Copy Project (Create Branch)
Copying a project allows for easy cloning of project content with just a click of a button. The resulting project will contain a child of all the live models of the source project and the same published models.
To copy a project, the user just needs to select a project from their project tree and click the copy project icon on the top-right.
The copy project screen closely resembles the project creation screen, requiring the user to input a new name and description for the new project. Additionally, the user must choose whether to copy the existing permissions from the source project to the copied project before saving.
PHENOM-Managed SDMs
PHENOM comes loaded with official FACE Shared Data Models (SDMs) for FACE Technical Standard Editions 2.1, 3.0, 3.1, and 3.2.
Creating a Project with an SDM
The user can create a project by importing a model file and/or selecting existing model.
If the user choses to import a model file containing an SDM, PHENOM will try to replace it with its managed version. This will allow the user to benefit from the ability to update SDM version in the future. During import, PHENOM will scan the model and if it detects a <dm/> node with the exact same name as one of the managed SDM model, it will try to replace it. However, if the imported SDM model contains more content than what is present in the "official" SDM, the swap will not occur (e.g. a custom measurement was added to package inside the SDM).
If for some reason, an expected SDM doesn't swap to a PHENOM-managed SDM, the user can proceed as follows to manually do it:
- Click on Create New Model and import the model file; this may lead to several models being created from the original file
- Click on Create New Project, and instead of uploading a file, select all the models that were created in step 1 except for the SDM one. Instead of selecting that SDM model, select one of the PHENOM-managed SDM models
- (Optional) Delete the SDM model that was created in step 1
Alternatively, the user can chose to create the project by using one of the SDMs in the list of existing models.
Update a Project's SDM model
If the project contains a PHENOM-managed SDM, the user has the ability to switch between versions of the SDM on the Project details page.
If the project contains a custom version of an SDM, it is possible to replace it with a PHENOM-managed. To do so, the user needs to follow these steps:
- Delete the original project containing the custom SDM. In the confirmation window, DO NOT select any constituent models for deletion
- Create a new project, and instead of uploading a file, select all the models that were included in the original deleted project except for the SDM one, and of the PHENOM-managed SDM models
- (Optional) Delete the custom SDM model
Sample Workflow
This section goes over a sample workflow which employs the PHENOM project and model structure concepts described in the sections above. In the scenario laid out below, a group of users, Chris, Dave, Nick, and Riley are working on different parts of completing a data model and documenting a set of interfaces against it. Each of them plays a slightly different role in the process, and they will use some of PHENOM's Model management features to keep their work organized.
Part 1 – Chris
Chris is working on updating the Shared Data Model (SDM) the group is using to conform to the latest changes released in an accepted standard. The user loads an SDM content file to create a model.
The user loads the model into an SDM_Editor project and begins to make the changes.
Once the user has made the changes necessary to match a decided-upon standard, the user publishes a version v1 of his SDM model.
Chris is going to make further changes in the SDM_Editor project, but that will be for the next standard update. In the meantime, the user wants to make the static version of the SDM they just published available to the rest of his team, so the user gives them Read permissions to it. However, making further changes to the SDM is his job and the user wants to stay in control of the process, so the user does not give any of his colleagues permissions to either the live version of the SDM model or the SDM_Editor project.
Part 2 – Dave
Dave is working on creating a Domain Specific Data Model (DSDM) for the team to use - he will be referencing the SDM Chris released in his efforts. He creates a new project into which he adds the SDM version he has access to and a blank model which will contain the DSDM content he creates.
After Dave has added some content to his DSDM model which references nodes in the SDM, he will see that his DSDM model is now listed as dependent on the SDM model he has been using – which means, it can no longer be loaded without it.
Nick and Riley will be documenting some interfaces against the domain model that Dave is working on. However, Dave does not want them to have to wait for him to have finished with all of his work before they can start. Also, as they work on their interface documentation, they may come up with good changes to the DSDM and suggest that they be included in Dave's work. So, Dave decided to share his project with Nick and Riley, giving them Read/Write permissions, which automatically gives them permissions to the active DSDM model version he's working on.
Part 3 – Nick & Riley
Nick and Riley will be documenting interfaces using the DSDM that was shared with them, but they will be working with different sets of interfaces, each in his own project. If they try to create a new project with just the DSDM, they will be rejected because they must also load in the SDM that was used to create it and on which it depends.
Once they have the appropriate permissions to all of the content, they can create their individual project with the models to house their documentation work separate from the contents of both the SDM and the DSDM. In the example below, Riley creates a RILEY_s_INTFC_DOC project including the DSDM_live model and a new blank model for his changes. By doing so, a new model, DSDM_IN_RILEY_S_INTFC_DOC, was created, inheriting from Dave’s DSDM_live.
Dave and Riley will now be able to independently edit DSDM content and merge changes between their two models as they see appropriate. Whenever Dave makes new updates to the DSDM, Nick and Riley have the opportunity to pull in those changes into their copies of the model. When either one of them makes a change to the DSDM portion of his project that he thinks should be included in the official version, they can make a push request to Dave's project that he can then either approve or ignore.
Push, Pull, and Approve Process
Pulling Changes from the Parent
Pull Request
Pulling allows you to get changes from the project you have inherited from. These changes can either be accepted or ignored.
To pull from your parent project, open the tab shown below:
Here you will be prompted to select nodes from the tree on the left or from the Merge Summary. You may choose to ignore certain changes and accept others. Any changes accepted will overwrite your current version of those model elements. The pull may fail and tell you that you are missing certain model elements. These could be something such as trying to merge an attribute of an entity without including the entity itself, or a Service but not the view that it points to, etc.
Pull Review Project
Instead of a traditional pull, you may decide to create a pull Review Project . Select the changes as you would in a traditional pull, but then check the 'New Review Project' option. You will need to specify a name and description of the pull Review Project. To ensure that the integrity of the model contents is maintained during review, you may also decide to enable Project Locking. Only one pull Review Project can exist per child.
To create a pull Review Project, see the image below:
After the pull Review Project is created, the pull page will display it's details.
Pushing Changes to the Parent
To push your changes to your parent project with a push request, open the tab shown below:
You may select any changes made in the tree on the left or from the Merge Summary, specify the push requests name and description, then press the "Request Push" button. This will not result in any change to your parent project yet, as these changes must be approved by someone with the correct permissions on your parent project.
Approving Changes from a Child
Push Request
To approve changes that have been requested from one of your children projects, open the tab shown below:
This tab shows any push requests as 'Merge Requests' that have been made by any of your child projects in addition to the completed and deleted push requests. On selection of one of these options, you may select which of the requested changes you would like to make to your model by selecting them in the tree on the left or from the Merge Summary, then hitting the 'Approve' button.
The merge may fail and tell you that you are missing certain model elements. These could be something such as trying to merge and attribute of an entity without including the entity itself, or a Service but not the view that it points to, etc.
Push Review Project
Instead of a traditional approve, you may decide to create a push Review Project instead. Select the changes as you would in a traditional push, but then check the 'New Review Project' option. You will need to specify a name and description of the push Review Project. To ensure that the integrity of the model contents is maintained during review, you may also decide to enable the Project Lock for the destination Project. Note that only one Review Project may exist per push request.
To create a push Review Project, see the image below:
After the Review Project is created, selecting the corresponding push request will display it's details.
Review Project
Review Projects 101
A Review Project in PHENOM is a temporary workspace created to show the user the outcome of a Push, Pull, or Approve before actual merging. This project provides unique tools to examine the proposed changes of a Push or Pull and enables users to modify their project without affecting the destination of the merge. The objectives of a Review Project are to:
- Allow data modeling prior to finalizing the merge
- Facilitate a thorough review of incoming changes
- Provide additional pages to aid the review process
Review Project Management
To learn about the creation of Review Projects, view the Push, Pull, and Approve Process.
When in PHENOM > Manage Models > Projects, the user can view the Review Projects they have access to under the destination Project within the Project Tree. Expand the destination Project in the Project Tree, then expand the Review Projects folder.
To view the corresponding push/pull request for your Review Project, simply select the Review Project from the Project Tree. The user can also access the the related Review Project for a push/pull request either on the pull or on the approve page where the Review Project was initiated.
Review projects can be modified like standard projects but cannot be copied, published, or restructured (changing the Models). Additionally, the Push, Pull, and Approve pages are consolidated into the Review Tab when switched to a Review Project, which contains pages specific to the Review Project.
Project Locking
When initiating a Review Project from either the pull or approve page, users have the option to secure the destination Project by selecting 'Lock Current Project During Review'. This lock ensures that no changes can be made to the modeling content while it's under review. Once the merge is ready to be finalized, the Project lock must be removed to finalize the merge. Multiple Review Projects can exist simultaneously so it is important for the user to manage the single lock on the destination Project during review.
Note that while Project locking is optional, it is encouraged to use the Project lock to prevent external changes being made to the destination Project during review.
Review Project Specific Pages
Finalize Merge
The Finalize Merge page serves as a central hub where users can finalize their merge and review the changes they've selected, either from the initial Review Project creation or from updates made on the Update Review page. Users may create a Commit directly from the Finalize Merge page, allowing them to establish a safety net before accepting or rejecting changes, without having to visit the Checkpoints page.
Accessed from a Review Project in PHENOM > Manage Models > Review > Finalize Merge, as seen below:
The 'Review Nodes' list connects each review change to its parent, as links, if available. This list lets users quickly access the change's details page to see the specific updates. Users can also view the review status from the Finalize Merge page, NavTree or the details page. For guidance on changing the review status of a change and or its children, please refer to the section on accepting, rejecting, & reviewing Changes.
Once users have altered the review status of proposed changes and other review project content, they can complete the merge process by clicking the 'Finalize Merge' button located in the top bar. Finalizing the merge will implement all pending and accepted changes, as well as any additional modifications made during the review process. Additionally the destination Project may be unlocked while finalizing the merge.
Below is an example of the finalize merge confirmation where there are pending changes and the destination project is locked. To proceed with the merge, the user should click 'Yes'. To review the remaining changes or make other edits, click 'No'.
If the destination Project isn't locked and has been altered during the review, a rebase will be required. Rebasing synchronizes the current review with the latest changes from the destination Project. After rebasing, the user can restart the process of finalizing the merge.
Checkpoints
The Checkpoints page lists each Checkpoint for the Review Project. Checkpoints enable users to roll back the Review Project to a previous version, reflecting the model content as it was at the time the Checkpoint was created.
Accessed from a Review Project in PHENOM > Manage Models > Review > Checkpoint, as seen below:
When the Review Project is initiated, an initial Checkpoint is always created. Additionally, the user can create a Checkpoint at any time during the review from the Checkpoint page or before rejection of review changes.
Users can rollback to any Checkpoint at any time. It's crucial to understand that rolling back to a Checkpoint will delete all subsequent Checkpoints and revert any changes made after that Checkpoint. To rollback to a Checkpoint, simply select the desired Checkpoint from the list, then click the 'Rollback To Checkpoint' icon located in the top bar of the page:
Update Review
The Update Review page is very similar to the pull page found in the Push, Pull, and Approve Process. Users can select additional changes from the push/pull request that were not initially chosen during the creation of the Review Project. These changes can either be accepted or ignored.
Accessed from a Review Project in PHENOM > Manage Models > Review > Update Review, as seen below:
Here you will be prompted to select nodes from the tree on the left or from the Merge Summary. You may choose to ignore certain changes and accept others. Any changes accepted will overwrite your current version of those model elements.
Accepting, Rejecting, & Reviewing Changes
These actions are crucial for managing proposed review changes and are accessible from the Finalize Merge page or the details page of a proposed change.
Accepting Changes
All proposed changes are initially pending and cannot be edited until accepted. Accepting a pending change indicates it is ready for merging. Once accepted and edited, the proposed change may not be reverted back to pending. Please note that pending changes will be automatically accepted when finalizing the merge.
Click the check icon to accept changes: 
Click the question mark icon to revert accepted changes back to pending:
Rejecting Changes
Rejecting a pending change will instantly restore it to its original state. Only changes that are still pending can be rejected. To safeguard against the irreversible nature of rejection, it is strongly advised to make a Commit before rejecting any changes.
Click the x-mark icon to reject changes: 
Reviewing Changes
Reviewing a change with the 'Review of Proposed Changes' popup enables users to compare the original state with the current proposed modifications. Differences are highlighted in bold in the proposed changes column.
Click the magnifying glass icon to review changes: 
Below is an example of reviewing proposed changes with edits.
Permissions
Permissions are a user's access level to either a project or a model. There are four different types of permissions, and a user can have any of the permissions types independent of one another. Permissions on a project and the models it contains are distinct (i.e., the user can have different permissions (higher or lower) at the project level compared to the models).
Permissions Types
Read Permissions
If a user has Read permissions, they have read-only access to the project or model.
Having Read permissions to a project and its models allows the user to switch to that project, see all the content, export the content, but not create, edit, or update it. In addition, if the model inherits from another model, a user with Read permissions is allowed to see the nodes that can be pulled from a parent model, but are prevented from actually pulling that content. Likewise, if a model has other models that inherit from it, a user with Read permissions to the model is allowed to see the push requests from the children models, but is not allowed to approve those changes.
Read permissions are unique from the other permissions types in that they are required in order to have any other permissions. For that reason, when assigning Write, Admin, or Owner permissions, Read permissions are assigned by default and can't be removed, as seen below.
Write Permissions
If a user has Write permissions, they are allowed to edit project and model content.
Having Write permissions to a project or a model allows the user to modify any of its content, including pulling, pushing, and approving push requests. Note that to pull changes from a parent model, the user needs at least Read permissions to the parent model.
Admin Permissions
If a user has Admin permissions, they are allowed to share the project or model and inherit from it
Having Admin permissions to a project or a model allows the user to create inheriting projects or models. Admin users can assign Read, Write, and Admin permissions to users belonging to their account for this particular project or model (including themselves).
Owner Permissions
If a user has Owner permissions, they have the same permissions as Admins, as well as some additional actions.
Having Owner permissions to a project or a model provide the user with Admin permissions plus the ability to delete the project or model, to change the metadata of it, and to share it with users external to their account. Owner users can assign Read, Write, and Admin permissions to internal and external users and grant Owner permissions to internal users.
Assign Permissions
When assigning permissions to users, note that all users can see who has permissions/access to the project if they have any permissions to the project. This capability is also available to users from other accounts, which will be listed under the "External Permissions" table. When making a copy of a project, there is also an option to "Copy all permissions." This will copy permissions for all internal and external users.
Assign Permissions to Internal Users
Users are able to assign permissions to their projects or models by using the Permission Manager on the Project or Model Details page. The table lists all the users from the same account as the current user.
To be able to share a Model, users need to have Admin or Owner permissions to it.
To be able to share a Project, users need to have Admin or Owner permissions to it and to all the models it contains. The permissions granted for the project will be applied to all its models.
Admin users can manage permissions among users within their account. Owner users can generate tokens to grant permissions to users in other accounts.
Assign Permissions to External Users
NOTE: For Enterprise installations with a single group account, all users are in the same group and permission tokens are not necessary. External refers to users outside of your organization's account but on the same PHENOM server.
To assign permissions to users that do not belong to the current user's account, the user has to give them a Permissions Token. The procedure to do so is as follows:
- Go to the Project Sharing page
- Locate the project or model to be shared
- Enter the username and the desired permissions level*
- Click the Share button
- Email the generated Token (which appeared on the right of the screen) to the user.
Note that the Token is only valid for 24 hours.
* The types of permissions users can grant follow the same policy as for internal users (see table above) except that they can't grant Owner permissions even if they have Owner permissions themselves.
To gain access to the project or model, the user has to go to the Project Sharing page, copy the token received by email in the dedicated field and click the submit button. The new project or model should then appear in the their project/model tree.
This user, along with any other external users, will appear in the Permissions Manager under a separate External Users table. The receiver will see any users on the sender's account who also have access to the content (model or project) shared. Both the sender of the token and the receiver of the token will be able to see the External Users table. If additional tokens are sent out to other accounts, all recipients will appear in the External Users permissions tables of all involved users; all users who have access to a project or model are able to see each other.
Account Admins
Account admins are able to see all the projects and models that users from their account have access to, and are able to assign permissions to those projects and models to any user in their account.
For internally created projects or models, Account admins can grant any types of permissions (including Owner) to any user in their account.
For a project or model that was externally shared with one (or more) of their account users, the Account admin can only assign permissions to other users if at least one of those original users was granted Admin permissions. In addition, if no one was granted Write access to the project or model, then Account admins will not be allowed to grant Write permissions to anyone, only Read and Admin.
Tutorials
These hands-on tutorials walk users through different exercises to learn different aspects of PHENOM.
Sample Workflows
Exercises
Video Tutorials
- Introduction & Navigation
- Importing Data Models
- Sharing Data Models
- Using Navigation Mode
- The Diagram Tool
- Configuration Management
- Subscription & User Management
- Expert Mode
- Tagging
Developing an Entity Model
Data Modeling is often a tedious process. It requires users to draw arrows in the right direction, create boxes with the correct labels. PHENOM makes this process much simpler. In this tutorial, we will walk through the construction, editing, and refactor of a simple entity model using the tools in PHENOM.
This tutorial will teach you how to create:
- Packages
- Entities
- Attributes
- Associations
Getting Prepared
Although you don't have to be a data modeling expert you do have to be a subject matter expert. If you aren't an expert, you should at least know a little something about the content you are trying to document. This tutorial was birthed in a training class where the attendees were really excited about rock climbing so we used their enthusiasm (and knowledge) to build a simple rock climbing data model.
For this exercise, we need to think about rock climbing and how we might organize some relationships between those things. The process is somewhat similar to building a highly normalized database schema, however, this tutorial will focus on the mechanics of building the data model instead of how to organize the information.
First Things First
Log into PHENOM. And click on the DATA MODEL icon.
Let's create a folder for the project. In the top-right quarter of the screen, you should see a create button. Click on that, and in the drop down, select Package.
For the name, enter "Rock_Climbing" - using a name like "Rock Climbing" will result in an invalid identifier error since spaces are not allowed.
For TYPE, choose CONCEPTUAL. This will create a package that can store conceptual items.
For PARENT PACKAGE, choose <ROOT>. This will create a package in the top level of the model.
Leave description blank for now.
In the upper right corner of this editor, click the SAVE button.
Now, the new ROCK_CLIMBING package should be visible in the NAV TREE.
Creating Your First Entity
Click on the Rock_Climbing package. This will ensure that your new entity is created in the correct place. If it isn't, that's okay. It can be dragged into the correct folder as needed.
Just like before, click on the CREATE button, however, this time, click on CONCEPTUAL → ENTITY in the drop down menu.
For the entity name, type "Wall". You may leave description blank.
Now, there is checkbox there that says, "Add UniqueIdentifier attribute". Make sure that is checked. This will save us a little work in a couple of minutes.
Click SAVE.
Tada! You have successfully created your first entity.
| Uh Oh. WHERE IS MY ENTITY!?!?! Your entity didn't appear in the Rock_Climbing package? Bummer. Take a look under PhenomEntities. Yeah...that's what I thought. Sorry about that. Just drag it into the Rock_Climbing package and remember this trick for later. (wink) |
Adding Attributes
Now that you've found your Wall entity and located it your Rock_Climbing package, double-click on it. This will open it up in the DETAILS viewer. In this view, you should see that one attribute has been added to your entity.
We really need to think about the kind of things we might need to document about our climbing wall. Let's start by adding a property to capture the general size of the wall.
Click the create button and a new line will be added to the list of attributes.
Enter "dimensions" for "enter new rolename." Don't worry about the description for now. Click in the TYPE box and scroll down to Extent. While this list is alphabetical, it lists "entities" first and then "associations", and then finally "observables" - so you are going to have to scroll down lower into the list.
Let's add one more attribute. Click "+Create" again and add an attribute named "grade" of type "Kind."
Click SAVE.
Composing an Entity
If you've ever been to a climbing gym, you may have noticed all of the little colored flags on the grips. These demarcate a "route" of a particular difficulty along with some other properties. As such, the route is not represented as a simple observable. Let's create another entity called Climbing_Route.
See if you can follow the steps above to create it.
Click SAVE.
Now, navigate back to wall. Click "+Create" to add a new attribute called "route" and, in the drop-down, select the new entity, "Climbing_Route."
Click SAVE.
Refactoring...
Now that we've created a route, we realize that the difficulty, or grade, is actually attached to the route instead of the wall. Let's fix that.
In the NavTree, expand the attributes under Wall by click on the small triangle and right-click on grade attribute.
This will popup a short menu with a "Move Attribute" action.
Click on that option and PHENOM will present the following dialog:
In the drop-down, select "Climbing_Wall." PHENOM will run a quick test to ensure the move is valid and then it will give you a brief warning:
Go ahead and click CONFIRM MOVE. Then, open the Climbing_Wall entity and you should see that the "grade" attribute has been moved into that entity.
| A Few Notes about Refactor... Refactor is a very powerful tool. If you have already documented interfaces that point to Wall.grade, refactor will automagically fix your path to say Wall.route.grade. That's one of the reasons that PHENOM won't let you pick any entity - you are constrained to picking an entity that is composed into the attribute's current entity. Skayl's developers are actively developing additional refactoring options that will possibly result in some more impactful events. The "impact summary" that appears in that second dialog will get a lot more interesting! |
Create the Climber
Although climbing walls are great, they are far better if we have some climbers that use them! So, let's create a rock climber entity.
Use PHENOM to create the following Entity. (HINT: if you let PHENOM automatically create the identifier attribute, you can rename it in the details page.)
How Many Times Did I Climb That?
Consider that we might want to count the number of times a climber has tried a climbing route. In which entity should we store that data? The climber? The wall? The route?
The answer is, none of them. If we put a counter in any of those, it would most like be pretty ambiguous. A counter on the wall would possibly be the number of climbs on the wall. And on the climber, the number of climbs the climber has.
For this, we need data to relate the Climber and the Climb_Route. Since this is relational data, we use an association. Fortunately, you pretty much know how to create one already.
Start by CREATING a new ENTITY called "Climbs_on_Route" and add an attribute called "number_of_climbs" with a type of "Count."
In the box immediately below the Attribute box, there is another box called Participants (Associated Entities).
Using the "+Create" button, go ahead and create two participants as shown below:
This association is relating the Climber and the Climbing_Route to one another and describes something (the number of climbs) about that relationship.
Click SAVE.
NOTE: At a very minimum, you must add two participants. It is possible to select the same entity twice (you could point to Climber two times), but it is important that you have a clear reason for doing so. In this case, maybe you are modeling a climbing buddy.
Extra Navigation in PHENOM
PHENOM provides several tools for navigation the types of relationships we just created. Let's take a look at those by going back to the Climbing_Route entity and scroll down to the box labeled "Composed In". You should see that "Wall" is listed in this box. This shows you all of the other entities that compose the current entity.
Below that, there is a box called "Associated In." In there, you can see the association(s) that point to this entity.
Along the top of the details panel, you should see a DIAGRAM tab. Click on that.
Drag your rock climbing entities and association into the diagram from the NavTree. Te resulting diagram should look a little something like the one below. My project has a couple of subtle differences.
Wrapping Up
That's it! You've exercised most of the basic features in PHENOM's Entity Modeler. You have learned how to create basic entities, add simple attributes (observables), add composed attributes, create associations, add associated entities, use basic diagramming capabilities, and perform basic refactoring.
Document Interfaces using PHENOM Portal
Documenting communication interfaces using good data modeling practices is easy in PHENOM Portal. This quick assignment will get you up and running documenting your own interfaces, creating valid and informative paths, and mapping your interface to others already documented.
Preparing PHENOM
In this tutorial, you will be documenting interfaces. However, in order for you to be able to do this, you need a data model that corresponds with this tutorial. Since there is already a tutorial for Developing an Entity Model, this tutorial will start by loading a data model into PHENOM.
Start by downloading this data model: File:Robot model.face
Switch to Manage Mode
All model management functions are performed in the Manage Models section of PHENOM. After logging in, please click on the Manage Models icon.
Create a New Project
It is possible to upload new content and create a new project all at once! To start, click on the Create New Project button.
| Two Buttons? If you have a project selected, a second button will appear. This is for Create Filtered Project which will be covered in another article.
 |
Select Models
Once you click the button, the following screen should appear to the right of the Project listing.
For the Project Name, please type: Robot
You may leave Description blank. This field is intended for you to capture notes about the project (or model) and how it will be used.
In the bottom-left of this display, there is a list of existing models. This is used to add existing models to the new project. Ignore this for now.
In the bottom-right, click on Import FACE model. This button will add a model entry as follows:
For the Model Name (the first text field), please enter: Robot_model
As before, Description can be left blank.
Click on Select files... and a file chooser will appear. Navigate to where you saved Robot_model.face from before and choose that file. PHENOM will immediately start uploading the file. While the file is uploading and being preprocessed, the following status will appear:
Once the file has successfully transferred, PHENOM will show the file uploaded successfully with a green indicator.
In the event of an error (e.g., invalid file type or invalid model), PHENOM will display an error as follows:
Once the file has been successfully uploaded, click on the SAVE button.
Switch to New Model
After saving the model, it will appear in the project browser. Simply right-click on Robot and choose Switch. This will load the new project and you are finally ready to start this tutorial!
You can verify that you have switched to the new project by looking at the top of your PHENOM display. The current project is displayed beside your username.
Prelude: Views, View-Characteristic, and Paths - What and Why
In the task of documenting the Simple Operating Robot Data Interface, our main focus will be in Views. Views can be understood as the documentation of messages that the interface describes. A view documents a message interface, and each view-characteristic documents a single field of the message. More specifically, a view-characteristic contains information about the logical level of the message field (such as the measurement and unit being used) as well as information about the conceptual level of the message field (which entities and properties of entities are being talked about).
If you click on a view-characteristic, you will see that each has a name, an observable, a measurement and axis (which further characterizes the observable), and a path documenting the entities and its context. Path development is the primary focus of this assignment - paths communicate the semantics of message fields in a machine understandable fashion. Engineer-written documentation for data coming in over the wire might indicate "Temperature of the main unit of an air system's propulsion system." which, though concise and informative, might not mean much to a machine. Paths allow us to write standardized descriptions of view-attributes, linking together different entities, such as engines, propulsion systems, and air vehicles, to create semantic, machine-readable documentation for the contents of a message. Below is an example view attribute describing the message field documented in the sentence above.
Take a look at the path and see if you can connect it to the meaning intended by the engineer from the previous paragraph. Note that this page also captures how the measurement of this concept is expressed (i.e., measurement units and frame of reference). This information is used to construct the Logical Data Model.
Part 1: Documenting Robot Position Status
The first message interface we have to implement is for communicating the Robot_Position_Status. We are given the following interface description:
| Field ID | Name & Description | Unit | Data Type |
|---|---|---|---|
| 1 | Robot_Id An alphanumeric string indicating the unique identifier of the robot system. |
UTF-8 | String |
| 2 | Latitude The WGS-84 latitude value. |
Radians | Double |
| 3 | Longitude The WGS-84 longitude value. |
Radians | Double |
| 4 | Altitude The altitude value expressed in MSL. |
Meters | Float |
Before documenting the message, take a look at the entity which this message is meant to describe. In the model we are using, the closest entity is Robot. Once you are logged into PHENOM, make sure that you click on the DATA MODELING button in the left-hand navigation panel. Then, type 'robot' into the search bar on top of Phenom's NavTree and bring up the page describing Robot. You will see that this entity is composed of a few attributes, some of them are observables while another is an entity.
Let's start the documentation by clicking the 'Create' button at the top left of the page and choosing to create a new view.
Give your view a name and a description following the information in the table at the top of this section and click save.
Once saved, you can find your new view in the tree by searching for it or opening its parent package. NOTE: PHENOM creates new views in the PhenomViews package. However, you may drag the elements into locations of your choosing (so long as they are valid).
Now, we can add an attribute to the view to describe the first field of the message - Robot_ID. To start, click on the CREATE button in the Attributes pane.
Fill in the View Attribute field with its name. The table indicates this should be: Robot_Id
Given the name and description from the table, it is not hard to think that the best observable for it is Identifier. Selected that as our observable, then choose a measurement that will likely best fulfill the id being a string - I chose UniqueID_UUID_Text_Meas.
The next step is slightly more complicated. Originally, in PHENOM you could simply select any primitive type, and PHENOM would generate the appropriate results. Unfortunately, this leads to a proliferation of platform data types and users wanted us to provide a little more control for platform type reuse.
This leads to two options. First, you can create a new platform type. This is absolutely necessary when working with a new model. Once some platform types have already been created, the second option will allow you to reuse and existing platform type.
Creating a Platform Type
Select a Platform Type
Integration Model to CinC Generation
This sample workflow will lead the user to generate FACE 3 CinC after creating necessary Mains, UoP Instances, and UoPs.
Create a UoP
First, create a UoP to be used by a UoP Instance within the model. A new UoP can be created by selecting the corresponding option in the 'Create>Integration' dropdown and then saving after inputting the necessary data.
Once the user has created their UoP it is now time to create the UoP Instance that will be used in CinC generation. This UoP Instance is going to be very important for later steps.
Create a UoP Instance
Similarly, new UoP Instance can be created by selecting the corresponding option in the 'Create>Integration' dropdown and then saving after inputting the required data .
Create a Context
The context is a visual diagram of the interactions between a UoP and the configurable elements of CinC.
- Add UoP Instance to the context.
- Find the UoP Instance in the navigation tree and select it
- Drag it onto the context.
- Add a Transporter to the context.
- In the horizontal toolbar on the left side of the diagram find and select the transporter block
- Drag the transporter block onto the diagram.
- Create a Transport Channel
- With the transporter block selected, on the right side find the Transport Channel control and click on the '+' to add a new channel
- Give the channel a name and click the save icon.
- Once the save completes, click on the transport channel drop down and select the name of the channel you just created.
- Connect the blocks
- Select the Uop Instance block in the diagram
- click on the up arrow at the upper right corner of the block and drag it over to the transporter block.
- A popup dialog will allow you to select the UoP port to connect to the transporter, select the port from the drop down list and click on save.
- Commit the changes.
- Click the Commit button under the heading Model on the diagram tool bar. This saves the changes to the Integration Model (IM) elements but does NOT save the diagram.
- Save the diagram
- click the middle disk icon under diagram in order to save the layout of the elements in the diagram. This saves the layout of the items in the diagram but does NOT save changes to the Integration or Deployment models that may have been made while editing the diagram elements.
Create a Main
The Main Program represents the executable program containing one (or more) UoPs and CinC.
- A new Main Program can be created by selecting the corresponding option in the 'Create>Deployment' dropdown and then saving after inputting the needed data including the UoP Instance.
Add a TPM
The transport protocol module is responsible for the serialization and deserialization of messages and their transport from one TPM to another or another system.
This step is optional as PHENOM will generate a UDP TPM by default.
- Within the Main detail page, after saving the main, click on the Create TPM button.
- Give the TPM a name ('tpm' is fine).
- Click the save button.
- Commit the changes to the main by clicking the disk icon in the upper right.
Generate CinC
- Next the user needs to open the 'Generate' section and click on the CinC submenu.
- The user should select 'CinC' as the artifact.
- Select the version of CinC you would like to generate
- Select include CinC Source and choose Yes.
- Select the Main and UoP Instances for the context we created above and make sure they are both checked
- Select the appropriate license.
- Click on the Generate button and a zip file will be created. The .zip file will contain the cinc source, the data modeled FACE types used by the UoP and the CinC configuration files. Save the file and extract the generated code.
Support
How Do I Submit a Ticket?
Please email us at support@skayl.com. We'll have you up and running as soon as possible.
How Can I Share Feedback & Report Bugs?
We welcome your feedback! If you've identified a bug or have recommendations for future features, please email us at support@skayl.com.