PHENOM Portal Knowledgebase - User contributions [en]

Entity and Association

2026-02-03T21:14:27Z

Nathalie: /* Adding/Editing Participants */

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.

[[File:Phenom-data model-details entity create.png|1000px|border]]

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...

[[File:Phenom-data model-details entity edit.png|1000px|border]]

== Adding/Editing Attributes ==
Click the Create button at the bottom of the Attributes section to add a new Attribute row. Attributes require a valid name and type. If not set, the Target Bounds will default to 0..* per the FACE® Technical Standard.

[[File:Attribute example.png|frameless|1500x1500px]]

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 Participants ==
Click the Create button at the bottom of the Participants section to add a new Participant row. Participants require a valid name and type. If not set, the Source Bounds will default to 0..* and the Target Bounds to 1..* perthe FACE Technical Standard.

[[File:Participant Example.png|frameless|1500x1500px]]

{{Info| 1= When you click "Create" in the Participants section for the first time, you will need to add two Participants. 
Adding Participants to an Entity will convert the Entity to an Association (since you're associating entities to each other)}}

Any Participants added or edited on the 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.

[[File:Phenom-data model-details entity move attr.png|1200px|border]]

In the dialog that appears, the user needs to select the Entity to which to move the selected Attribute.

[[File:Phenom-data model-details entity move attr dest.png|400px|border]]
[[File:Phenom-data model-details entity move attr confirm.png|400px|border]]

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:

[[File:Phenom-data model-details entity delete attr.png|1000px|border]]

The delete button in the upper right will delete the entire Entity/Association and all of its children:

[[File:Phenom-data model-details entity delete.png|1000px|border]]

 

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.

[[File:Phenom-data model-details entity delete confirmation.png|600px|border]]

 

{{Info| 1= 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.

[[File:Phenom-data model-details entity last modified by.png|1000px|border]]

=== Attributes → Views ===
If an attribute is used by a View Characteristic, an expandable list appears in the Projectors column.

[[File:Phenom-data model-details entity projections.png|1000px|border]]

=== Composed In ===
Entities/Associations that have attributes of type the currently viewed entity/association will appear in the "Composed in" section.

[[File:Phenom-data model-details entity composed in.png|1000px|border]]

=== Associated In ===
Associations that have associated entities of type the currently viewed entity/association will appear in the "Associated in" section.

[[File:Phenom-data model-details entity associated in.png|1000px|border]]

[[Index.php?title=Category:UserGuide|009_Entity_and_Association]]

Entity and Association

2026-02-03T21:14:12Z

Nathalie: /* Adding/Editing Attributes */

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.

[[File:Phenom-data model-details entity create.png|1000px|border]]

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...

[[File:Phenom-data model-details entity edit.png|1000px|border]]

== Adding/Editing Attributes ==
Click the Create button at the bottom of the Attributes section to add a new Attribute row. Attributes require a valid name and type. If not set, the Target Bounds will default to 0..* per the FACE® Technical Standard.

[[File:Attribute example.png|frameless|1500x1500px]]

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 Participants ==
Click the Create button at the bottom of the Participants section to add a new Participant row. Participants require a valid name and type. If not set, the Source Bounds will default to 0..* and the Target Bounds to 1..* perthe FACE Technical Standard.

[[File:Participant Example.png|frameless|1500x1500px]]

{{Info| 1= When you click "Create" in the Participants section for the first time, you will need to add two Participants. 
Adding Participants to an Entity will convert the Entity to an Association (since you're associating entities to each other)}}

Any Participants 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.

[[File:Phenom-data model-details entity move attr.png|1200px|border]]

In the dialog that appears, the user needs to select the Entity to which to move the selected Attribute.

[[File:Phenom-data model-details entity move attr dest.png|400px|border]]
[[File:Phenom-data model-details entity move attr confirm.png|400px|border]]

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:

[[File:Phenom-data model-details entity delete attr.png|1000px|border]]

The delete button in the upper right will delete the entire Entity/Association and all of its children:

[[File:Phenom-data model-details entity delete.png|1000px|border]]

 

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.

[[File:Phenom-data model-details entity delete confirmation.png|600px|border]]

 

{{Info| 1= 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.

[[File:Phenom-data model-details entity last modified by.png|1000px|border]]

=== Attributes → Views ===
If an attribute is used by a View Characteristic, an expandable list appears in the Projectors column.

[[File:Phenom-data model-details entity projections.png|1000px|border]]

=== Composed In ===
Entities/Associations that have attributes of type the currently viewed entity/association will appear in the "Composed in" section.

[[File:Phenom-data model-details entity composed in.png|1000px|border]]

=== Associated In ===
Associations that have associated entities of type the currently viewed entity/association will appear in the "Associated in" section.

[[File:Phenom-data model-details entity associated in.png|1000px|border]]

[[Index.php?title=Category:UserGuide|009_Entity_and_Association]]

Entity and Association

2026-02-03T21:13:52Z

Nathalie:

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.

[[File:Phenom-data model-details entity create.png|1000px|border]]

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...

[[File:Phenom-data model-details entity edit.png|1000px|border]]

== Adding/Editing Attributes ==
Click the Create button at the bottom of the Attributes section to add a new Attribute row. Attributes require a valid name and type. If not set, the Target Bounds will default to 0..* per the FACE® Technical Standard.

[[File:Attribute example.png|frameless|1500x1500px]]

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 Participants ==
Click the Create button at the bottom of the Participants section to add a new Participant row. Participants require a valid name and type. If not set, the Source Bounds will default to 0..* and the Target Bounds to 1..* perthe FACE Technical Standard.

[[File:Participant Example.png|frameless|1500x1500px]]

{{Info| 1= When you click "Create" in the Participants section for the first time, you will need to add two Participants. 
Adding Participants to an Entity will convert the Entity to an Association (since you're associating entities to each other)}}

Any Participants 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.

[[File:Phenom-data model-details entity move attr.png|1200px|border]]

In the dialog that appears, the user needs to select the Entity to which to move the selected Attribute.

[[File:Phenom-data model-details entity move attr dest.png|400px|border]]
[[File:Phenom-data model-details entity move attr confirm.png|400px|border]]

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:

[[File:Phenom-data model-details entity delete attr.png|1000px|border]]

The delete button in the upper right will delete the entire Entity/Association and all of its children:

[[File:Phenom-data model-details entity delete.png|1000px|border]]

 

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.

[[File:Phenom-data model-details entity delete confirmation.png|600px|border]]

 

{{Info| 1= 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.

[[File:Phenom-data model-details entity last modified by.png|1000px|border]]

=== Attributes → Views ===
If an attribute is used by a View Characteristic, an expandable list appears in the Projectors column.

[[File:Phenom-data model-details entity projections.png|1000px|border]]

=== Composed In ===
Entities/Associations that have attributes of type the currently viewed entity/association will appear in the "Composed in" section.

[[File:Phenom-data model-details entity composed in.png|1000px|border]]

=== Associated In ===
Associations that have associated entities of type the currently viewed entity/association will appear in the "Associated in" section.

[[File:Phenom-data model-details entity associated in.png|1000px|border]]

[[Index.php?title=Category:UserGuide|009_Entity_and_Association]]

Dashboard

2025-12-08T19:41:51Z

Nathalie:

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.

[[File:Phenom dashboard 1.jpg|1000px|border|center]]

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.

[[File:Phenom dashboard 2.jpg|1000px|border|center]]

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.

[[File:Phenom dashboard 3.jpg|1000px|border|center]]

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.

[[File:Phenom dashboard 5.jpg|1000px|border|center]]

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.

[[File:Phenom dashboard 4.jpg|1000px|border|center]]

[[Category:UserGuide|005_Dashboard]]

Login

2025-12-08T19:38:55Z

Nathalie:

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]])

[[File:PHENOM_Login_Screenshot.png|400px|border]]

== 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”:

[[File:Phenom Password Request Step 1.png|600px|border]]

Enter your username and click “Request Reset”:

[[File:Phenom Password Request Step 2.png|600px|border]]

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):

[[File:Phenom Password Request Step 3.png|800px|border]]

Enter a new password, click “Reset Password”.

[[File:Phenom Password Request Step 4.png|800px|border]]

Login with your username and new password.

[[File:PHENOM_Login_Screenshot.png|400px|border]]

[[Category:UserGuide|003_Login]]

Login

2025-12-08T19:37:24Z

Nathalie:

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]])

[[File:PHENOM_Login_Screenshot.png|500px|border]]

== 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”:

[[File:Phenom Password Request Step 1.png|500px|border]]

Enter your username and click “Request Reset”:

[[File:Phenom Password Request Step 2.png|500px|border]]

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):

[[File:Phenom Password Request Step 3.png|500px|border]]

Enter a new password, click “Reset Password”.

[[File:Phenom Password Request Step 4.png|500px|border]]

Login with your username and new password.

[[File:PHENOM_Login_Screenshot.png|500px|border]]

[[Category:UserGuide|003_Login]]

Formatting a CSV for View Import

2025-11-14T15:58:17Z

Nathalie:

To bulk import view characteristics, the CSV file should be formatted as described in this article.

== General Column/Data Requirements ==
The following column headers must exist and contain data in each row:
* View_Name
* Characteristic_Name
* Primitive
* Source
* Path
* Measurement

The following columns are optional (for example, the Package columns are only there to specify destination if desired):
* Package_Name
* Package_Description
* Package_Tags
* View_Description
* View_Tags
* Characteristic_Description
* Characteristic_Tags
* Lower_Bound
* Upper_Bound
* Nested_View

The order of the columns is not enforced, it does not have to be in the same order as the suggested format above.

Any additional user-made columns will be ignored and will not interfere with import.

Bulk import can currently import Package, View, and Characteristic elements.

== Column-specific Requirements ==
=== Package Name ===
* Leaving this column blank will default Package to the "Phenom" package.
* Setting this column to an existing Package will default to the first matching Platform Package within the model.
* If there is no matching Package, a new Package will be created within the "Phenom" Package.

=== Package Description ===
Package Description will be imported for new Packages only. Only the first Description for new Packages will be imported.

=== View Name ===
The data in this column for an existing View will be matched to the first View of that name within the model (there should only be one match). If there isn't a matching View, a new View will be created within the "Phenom" Package.

=== View Description ===
View Description will be imported for new Views only. Only the first Description for new Views will be imported.

=== Characteristic Name, Characteristic Description ===
* Characteristic Names must be unique to the View they are imported under.
* The Characteristic must not already exist in the desired View
* Characteristics belonging to different Views may have the same name.

=== Primitive ===
This column isn't case sensitive. Acceptable values: "Char", "Double", "Float", "Long", "Short", "String", "ULong", "UShort", "Octet", "Enumeration".

=== Source, Path, Measurement ===
* Source must exist in the model and must be the Entity/Association projected from the last element in the Path column.
* Path must have valid elements leading up to/ending with the Observable realized by the Measurement.
* Measurement must in the model and realize the Observable at the end of the Path.

''For example: '''AirSystemType''' is projected (through payload) from '''elementID''' which is realized by ''UniqueID_Unbounded_Integer'

=== Lower Bound and Upper Bound ===

* This row must have both a Source and a Path for these values to be valid

=== Nested View ===

* The Nested View must exist in the model and must be the name of a View.
''See Nested Views for changes to other columns''

== Tagging New Elements (Optional) ==
Package_Tags, View_Tags, and Characteristic_Tags optional columns can be used to tag new Packages, Views, or Characteristics. Each field can have multiple comma-delimited tags.

The raw CSV must have quotes around fields with commas (Excel normally handles this).

Package_Tags will tag whichever package is chosen - this includes the Phenom package when a package isn't specified in the Package_Name column.

== Nested Views Requirements ==
By referencing the name of another view, whether already existing in the model or being added by the same CSV file, in the '''Nested_View''' column, the import can create view sub-structuring or nesting.

In view field rows representing nested views, the '''Source''' and '''Path''' columns represent the perspective path under which the view sub-structure is nested. At the same time, the '''Primitive''', '''Platform_Type''', and '''Measurement''' are not applicable.

By default, all sub-structure nesting view field rows will be inferred to be representing a "private" nesting. This can be made explicit, or toggled off to accomplish a sub-structure import, by using the '''Characteristic_Foreign''' column: if set to "false", the view sub-structure will be private to its nesting view, and an independent import if set to "true".

== Union Views Requirements ==
Union views are not supported by the CSV import yet.

== Additional Requirements ==
* Data within Package_Name, View_Name, and Characteristic_Name must all begin with a letter, and only contain numbers, letters, or underscores. The data must also not match any of the following reserved words:
** '''IDL Reserved words:'''"and", "begin", "break", "case", "common", "compile_opt", "continue", "do", "else", "end", "endcase", "endelse", "endfor", "endforeach", "endif", "endrep", "endswitch", "endwhile", "eq", "for", "foreach", "forward_function", "function", "ge", "goto", "gt", "if", "inherits", "le", "lt", "mod", "ne", "not", "of", "on_ioerror", "or", "pro", "repeat", "switch", "then", "until", "while", "xor"
** '''OCL Reserved words:''' "abstract", "any", "attribute", "boolean", "case", "char", "component", "const", "consumes", "context", "custom", "default", "double", "emits", "enum", "eventtype", "exception", "factory", "false", "finder", "fixed", "float", "getraises", "home", "import", "in", "inout", "interface", "local", "long", "manages", "module", "multiple", "native", "object", "octet", "oneway", "out", "primarykey", "private", "provides", "public", "publishes", "raises", "readonly", "sequence", "setraises", "short", "string", "struct", "supports", "switch", "true", "truncatable", "typedef", "typeid", "typeprefix", "union", "unsigned", "uses", "valuebase", "valuetype", "void", "wchar", "wstring"
* New Views not already within the model must be unique among elements of type IDLStruct and Enumeration.
* Multidimensional Measurements are supported, however each axis will default to the primitive found within the primitive column (these can be corrected within Phenom later if desired).
* If there are any errors during validation of the CSV file, the model import will not be initiated and a list of errors will be returned. They will be labeled by the row they occur on for convenience.
* There is a 2MB limit in place - if a larger file needs to be imported, it needs to be split up into smaller files.
* In the raw CSV (i.e., as observed from notepad), any field with commas must have surrounding quotes (Excel normally handles this).

Formatting a CSV for View Import

2025-11-14T15:57:39Z

Nathalie: /* Nested Views */

To bulk import view characteristics, the CSV file should be formatted as described in this article.

== General Column/Data Requirements ==
The following column headers must exist and contain data in each row:
* View_Name
* Characteristic_Name
* Primitive
* Source
* Path
* Measurement

The following columns are optional (for example, the Package columns are only there to specify destination if desired):
* Package_Name
* Package_Description
* Package_Tags
* View_Description
* View_Tags
* Characteristic_Description
* Characteristic_Tags
* Lower_Bound
* Upper_Bound
* Nested_View

The order of the columns is not enforced, it does not have to be in the same order as the suggested format above.

Any additional user-made columns will be ignored and will not interfere with import.

Bulk import can currently import Package, View, and Characteristic elements.

== Column-specific Requirements ==
=== Package Name ===
* Leaving this column blank will default Package to the "Phenom" package.
* Setting this column to an existing Package will default to the first matching Platform Package within the model.
* If there is no matching Package, a new Package will be created within the "Phenom" Package.

=== Package Description ===
Package Description will be imported for new Packages only. Only the first Description for new Packages will be imported.

=== View Name ===
The data in this column for an existing View will be matched to the first View of that name within the model (there should only be one match). If there isn't a matching View, a new View will be created within the "Phenom" Package.

=== View Description ===
View Description will be imported for new Views only. Only the first Description for new Views will be imported.

=== Characteristic Name, Characteristic Description ===
* Characteristic Names must be unique to the View they are imported under.
* The Characteristic must not already exist in the desired View
* Characteristics belonging to different Views may have the same name.

=== Primitive ===
This column isn't case sensitive. Acceptable values: "Char", "Double", "Float", "Long", "Short", "String", "ULong", "UShort", "Octet", "Enumeration".

=== Source, Path, Measurement ===
* Source must exist in the model and must be the Entity/Association projected from the last element in the Path column.
* Path must have valid elements leading up to/ending with the Observable realized by the Measurement.
* Measurement must in the model and realize the Observable at the end of the Path.

''For example: '''AirSystemType''' is projected (through payload) from '''elementID''' which is realized by ''UniqueID_Unbounded_Integer'

=== Lower Bound and Upper Bound ===

* This row must have both a Source and a Path for these values to be valid

=== Nested View ===

* The Nested View must exist in the model and must be the name of a View.
''See Nested Views for changes to other columns''

== Tagging New Elements (Optional) ==
Package_Tags, View_Tags, and Characteristic_Tags optional columns can be used to tag new Packages, Views, or Characteristics. Each field can have multiple comma-delimited tags.

The raw CSV must have quotes around fields with commas (Excel normally handles this).

Package_Tags will tag whichever package is chosen - this includes the Phenom package when a package isn't specified in the Package_Name column.

== Nested Views Requirements ==
By referencing the name of another view, whether already existing in the model or being added by the same CSV file, in the '''Nested_View''' column, the import can create view sub-structuring or nesting.

In view field rows representing nested views, the '''Source''' and '''Path''' columns represent the perspective path under which the view sub-structure is nested. At the same time, the '''Primitive''', '''Platform_Type''', and '''Measurement''' are not applicable.

By default, all sub-structure nesting view field rows will be inferred to be representing a "private" nesting. This can be made explicit, or toggled off to accomplish a sub-structure import, by using the '''Characteristic_Foreign''' column: if set to "false", the view sub-structure will be private to its nesting view, and an independent import if set to "true".

== Additional Requirements ==
* Data within Package_Name, View_Name, and Characteristic_Name must all begin with a letter, and only contain numbers, letters, or underscores. The data must also not match any of the following reserved words:
** '''IDL Reserved words:'''"and", "begin", "break", "case", "common", "compile_opt", "continue", "do", "else", "end", "endcase", "endelse", "endfor", "endforeach", "endif", "endrep", "endswitch", "endwhile", "eq", "for", "foreach", "forward_function", "function", "ge", "goto", "gt", "if", "inherits", "le", "lt", "mod", "ne", "not", "of", "on_ioerror", "or", "pro", "repeat", "switch", "then", "until", "while", "xor"
** '''OCL Reserved words:''' "abstract", "any", "attribute", "boolean", "case", "char", "component", "const", "consumes", "context", "custom", "default", "double", "emits", "enum", "eventtype", "exception", "factory", "false", "finder", "fixed", "float", "getraises", "home", "import", "in", "inout", "interface", "local", "long", "manages", "module", "multiple", "native", "object", "octet", "oneway", "out", "primarykey", "private", "provides", "public", "publishes", "raises", "readonly", "sequence", "setraises", "short", "string", "struct", "supports", "switch", "true", "truncatable", "typedef", "typeid", "typeprefix", "union", "unsigned", "uses", "valuebase", "valuetype", "void", "wchar", "wstring"
* New Views not already within the model must be unique among elements of type IDLStruct and Enumeration.
* Multidimensional Measurements are supported, however each axis will default to the primitive found within the primitive column (these can be corrected within Phenom later if desired).
* If there are any errors during validation of the CSV file, the model import will not be initiated and a list of errors will be returned. They will be labeled by the row they occur on for convenience.
* There is a 2MB limit in place - if a larger file needs to be imported, it needs to be split up into smaller files.
* In the raw CSV (i.e., as observed from notepad), any field with commas must have surrounding quotes (Excel normally handles this).

Formatting a CSV for View Import

2025-11-14T15:57:05Z

Nathalie: /* Nested View */

To bulk import view characteristics, the CSV file should be formatted as described in this article.

== General Column/Data Requirements ==
The following column headers must exist and contain data in each row:
* View_Name
* Characteristic_Name
* Primitive
* Source
* Path
* Measurement

The following columns are optional (for example, the Package columns are only there to specify destination if desired):
* Package_Name
* Package_Description
* Package_Tags
* View_Description
* View_Tags
* Characteristic_Description
* Characteristic_Tags
* Lower_Bound
* Upper_Bound
* Nested_View

The order of the columns is not enforced, it does not have to be in the same order as the suggested format above.

Any additional user-made columns will be ignored and will not interfere with import.

Bulk import can currently import Package, View, and Characteristic elements.

== Column-specific Requirements ==
=== Package Name ===
* Leaving this column blank will default Package to the "Phenom" package.
* Setting this column to an existing Package will default to the first matching Platform Package within the model.
* If there is no matching Package, a new Package will be created within the "Phenom" Package.

=== Package Description ===
Package Description will be imported for new Packages only. Only the first Description for new Packages will be imported.

=== View Name ===
The data in this column for an existing View will be matched to the first View of that name within the model (there should only be one match). If there isn't a matching View, a new View will be created within the "Phenom" Package.

=== View Description ===
View Description will be imported for new Views only. Only the first Description for new Views will be imported.

=== Characteristic Name, Characteristic Description ===
* Characteristic Names must be unique to the View they are imported under.
* The Characteristic must not already exist in the desired View
* Characteristics belonging to different Views may have the same name.

=== Primitive ===
This column isn't case sensitive. Acceptable values: "Char", "Double", "Float", "Long", "Short", "String", "ULong", "UShort", "Octet", "Enumeration".

=== Source, Path, Measurement ===
* Source must exist in the model and must be the Entity/Association projected from the last element in the Path column.
* Path must have valid elements leading up to/ending with the Observable realized by the Measurement.
* Measurement must in the model and realize the Observable at the end of the Path.

''For example: '''AirSystemType''' is projected (through payload) from '''elementID''' which is realized by ''UniqueID_Unbounded_Integer'

=== Lower Bound and Upper Bound ===

* This row must have both a Source and a Path for these values to be valid

=== Nested View ===

* The Nested View must exist in the model and must be the name of a View.
''See Nested Views for changes to other columns''

== Tagging New Elements (Optional) ==
Package_Tags, View_Tags, and Characteristic_Tags optional columns can be used to tag new Packages, Views, or Characteristics. Each field can have multiple comma-delimited tags.

The raw CSV must have quotes around fields with commas (Excel normally handles this).

Package_Tags will tag whichever package is chosen - this includes the Phenom package when a package isn't specified in the Package_Name column.

== Nested Views ==
By referencing the name of another view, whether already existing in the model or being added by the same CSV file, in the '''Nested_View''' column, the import can create view sub-structuring or nesting.

In view field rows representing nested views, the '''Source''' and '''Path''' columns represent the perspective path under which the view sub-structure is nested. At the same time, the '''Primitive''', '''Platform_Type''', and '''Measurement''' are not applicable.

By default, all sub-structure nesting view field rows will be inferred to be representing a "private" nesting. This can be made explicit, or toggled off to accomplish a sub-structure import, by using the '''Characteristic_Foreign''' column: if set to "false", the view sub-structure will be private to its nesting view, and an independent import if set to "true".

== Additional Requirements ==
* Data within Package_Name, View_Name, and Characteristic_Name must all begin with a letter, and only contain numbers, letters, or underscores. The data must also not match any of the following reserved words:
** '''IDL Reserved words:'''"and", "begin", "break", "case", "common", "compile_opt", "continue", "do", "else", "end", "endcase", "endelse", "endfor", "endforeach", "endif", "endrep", "endswitch", "endwhile", "eq", "for", "foreach", "forward_function", "function", "ge", "goto", "gt", "if", "inherits", "le", "lt", "mod", "ne", "not", "of", "on_ioerror", "or", "pro", "repeat", "switch", "then", "until", "while", "xor"
** '''OCL Reserved words:''' "abstract", "any", "attribute", "boolean", "case", "char", "component", "const", "consumes", "context", "custom", "default", "double", "emits", "enum", "eventtype", "exception", "factory", "false", "finder", "fixed", "float", "getraises", "home", "import", "in", "inout", "interface", "local", "long", "manages", "module", "multiple", "native", "object", "octet", "oneway", "out", "primarykey", "private", "provides", "public", "publishes", "raises", "readonly", "sequence", "setraises", "short", "string", "struct", "supports", "switch", "true", "truncatable", "typedef", "typeid", "typeprefix", "union", "unsigned", "uses", "valuebase", "valuetype", "void", "wchar", "wstring"
* New Views not already within the model must be unique among elements of type IDLStruct and Enumeration.
* Multidimensional Measurements are supported, however each axis will default to the primitive found within the primitive column (these can be corrected within Phenom later if desired).
* If there are any errors during validation of the CSV file, the model import will not be initiated and a list of errors will be returned. They will be labeled by the row they occur on for convenience.
* There is a 2MB limit in place - if a larger file needs to be imported, it needs to be split up into smaller files.
* In the raw CSV (i.e., as observed from notepad), any field with commas must have surrounding quotes (Excel normally handles this).

CSV

2025-08-22T21:23:22Z

Nathalie:

The CSV import tool allows users to bulk import data into their model.

[[File:Phenom-data model-import csv.png|1200px|border]]

To import a CSV file,
* Select the type of data from the Import Type dropdown. Selecting the "... UPDATE" option for any type of data will overwrite existing information.
* Under Import File, select a properly formatted CSV file (formatting rules are provided below)
* Click the Import button on the lower right side

The import might take some time depending on the size of the file. After the import finishes, a success message or an Import Errors message with each error and its respective row will be displayed.

[[File:Phenom-data model-import csv update.png|1200px|border]]

The types of data the user can import are:
* View characteristic (see [[Formatting a CSV for View Import]])
* Enumeration literal (see [[Formatting a CSV for Enum Import]])
* Entity and Association (see [[Formatting a CSV for Entities and Associations Import]])
* Constraint
* Platform Type

Formatting a CSV for Model Content Import

2025-08-22T21:23:06Z

Nathalie: Nathalie moved page Formatting a CSV for Model Content Import to Formatting a CSV for Entities and Associations Import

#REDIRECT [[Formatting a CSV for Entities and Associations Import]]

Formatting a CSV for Entities and Associations Import

2025-08-22T21:23:06Z

Nathalie: Nathalie moved page Formatting a CSV for Model Content Import to Formatting a CSV for Entities and Associations Import

To bulk import model content, the CSV file should be formatted as described in this article.

{{Info| 1=Each row of the CSV creates one attribute on an element. Creation of new elements is incidental and done only if a match isn't found.}}

== General Column/Data Requirements ==
The following column headers must exist and contain data in each row:
* Element_Name
* Operation_Type
* Attribute_Name
* Attribute_Type

The following columns are optional:
* Element_Description
* Element_Tags
* Attribute_Description
* Attribute_Tags
* Association_Path
* Package_Name
* Package_Description
* Package_Tags

== Column-specific Requirements ==
=== Element Name & Description ===
* If an Entity (or Association) with a matching name is found in the model, the attribute will be added to it.
* New created elements default to a type of Entity.
* If an Entity (or Association) is created, the description is applied to that new element. If the element already exists, its description (if not an empty string) will be updated with the description provided here.

=== Operation Type & Association Path ===
* Must be set to 'Composition' or 'Association'. If Operation_Type is Association, then the Element will automatically be turned into an Association.
* If the Attribute already exists, it will be updated to be an Associated Entity (i.e., turns the Entity into an Association)
* There '''MUST BE AT LEAST TWO''' associated entities or the creation/update operation will fail. It is possible to only add a single associated entity if the element already exists and already contains an associated entity.
* By default, the Association Path is empty. This is an advanced concept used to relate to specific attributes of an element rather than the entire element itself.

=== Attribute Name, Type & Description ===
* Attribute_Name is the desired name for the attribute.
* Attribute_Type must be a valid Observable, Entity, or Association that either
** exists in the model, or
** was created on a previous row.
* Attribute_Description is the description that will be applied to that attribute. If the attribute already exists, its description (if not an empty string) will be updated with the description provided here.

=== Package Name & Description ===
* These columns allow you to place new entity in the package specified by Package_Name. If a package with the provided name does not exist, the new package will be created under the PhenomEntities package.
* Package_Name specified the name of the existing/new package.
* Package_Description specifies the description that will be applied to that package.

== Tagging (Optional) ==
* Optional columns can be added in to CSV to tag new Packages, Elements, or Attributes.
* Each field can have multiple comma delimited tags.

CSV

2025-08-22T21:22:44Z

Nathalie:

The CSV import tool allows users to bulk import data into their model.

[[File:Phenom-data model-import csv.png|1200px|border]]

To import a CSV file,
* Select the type of data from the Import Type dropdown. Selecting the "... UPDATE" option for any type of data will overwrite existing information.
* Under Import File, select a properly formatted CSV file (formatting rules are provided below)
* Click the Import button on the lower right side

The import might take some time depending on the size of the file. After the import finishes, a success message or an Import Errors message with each error and its respective row will be displayed.

[[File:Phenom-data model-import csv update.png|1200px|border]]

The types of data the user can import are:
* View characteristic (see [[Formatting a CSV for View Import]])
* Enumeration literal (see [[Formatting a CSV for Enum Import]])
* Entity and Association (see [[Formatting a CSV for Model Content Import]])
* Constraint
* Platform Type

CSV

2025-08-22T21:21:58Z

Nathalie:

The CSV import tool allows users to bulk import data into their model.

[[File:Phenom-data model-import csv.png|1200px|border]]

To import a CSV file,
* Select the type of data from the Import Type dropdown. Selecting the "... UPDATE" option for any type of data will overwrite existing information.
* Under Import File, select a properly formatted CSV file (formatting rules are provided below)
* Click the Import button on the lower right side

The import might take some time depending on the size of the file. After the import finishes, a success message or an Import Errors message with each error and its respective row will be displayed.

[[File:Phenom-data model-import csv update.png|1200px|border]]

The types of data the user can import are:
* View characteristic (see [[Formatting a CSV for View Import]])
* Enumeration literal (see [[Formatting a CSV for Enum Import]])
* Model content (see [[Formatting a CSV for Model Content Import]])
* Constraints
* Platform Types

CSV

2025-08-22T21:21:11Z

Nathalie:

The CSV import tool allows users to bulk import data into their model.

[[File:Phenom-data model-import csv.png|1200px|border]]

To import a CSV file,
* Select the type of data from the Import Type dropdown. Selecting the "... UPDATE" option for any type of data will overwrite existing information.
* Under Import File, select a properly formatted CSV file (formatting rules are provided below)
* Click the Import button on the lower right side

The import might take some time depending on the size of the file. After the import finishes, a success message or an Import Errors message with each error and its respective row will be displayed.

[[File:Phenom-data model-import csv update.png|1200px|border]]

The types of data the user can import are:
* View-Characteristic (see [[Formatting a CSV for View Import]])
* Enum-Literal (see [[Formatting a CSV for Enum Import]])
* Model-Content (see [[Formatting a CSV for Model Content Import]])
* Constraints
* Platform Types

Import

2025-08-22T21:20:57Z

Nathalie: /* CSV */

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#Projects Management|Projects and Models Management]] page.

== [[CSV]] ==
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

== [[Placeholders]] ==
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'''
[[File:Placeholder1.jpg|thumb|none]]

In this example we are using the AcccelerationPlaceholderMeasurement.

[[File:Placeholder2.jpg|none|thumb]]
When we're ready to revise the project, the placeholder usage will appear in the health check.

== [[Merge External Model]] ==
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.

PHENOM Installation

2025-08-07T13:57:57Z

Nathalie:

This page details the requirements for an on-site installation of the PHENOM application. PHENOM is a web-application reached by users via a web browser. As such, it requires the setup of a web-server along with supporting packages and application code in an environment from which it can reach its intended users.

While Skayl is always happy to assist our customers’ use of PHENOM, we are not able to provide comprehensive IT support for every enterprise environment in which the application may be deployed. As such, the customer is responsible for the setup, configuration, and maintenance of the internal IT infrastructure from which they decide to serve PHENOM to users. The sections below will enumerate the basic requirements of such setup but should not be considered an exhaustive listing of the potential IT support needs of a system hosting PHENOM.

Information about [[PHENOM Maintenance]] can be found here.

=Hardware Requirements=
It is recommended that the machine running PHENOM be configured with at least the following hardware:
* 4 CPU cores
* 32 GB of RAM
* 200 GB of drive space

=VM Deployment (Default)=
PHENOM can be provided fully installed and ready-to-run in a pre-packaged virtual machine to be hosted within the customer’s infrastructure. The machine can be delivered in one of the following formats, as exported by VirtualBox:

* OVF 0.9
* OVF 1.0
* OVF 2.0

The operating system on the provided virtual machine can be any of the following:

* Debian 11
* RHEL 8
* RHEL 9

It is the customer’s responsibility to ensure that they can import a VM of the selected format into their virtualization system and configure it to connect to any necessary networks. After installation, it is also the customer’s responsibility to keep the operating system of the installed virtual machine maintained and updated in accordance with their enterprise’s security and IT policies.

=Installer Deployment=
Alternatively, Skayl can provide an installer bundle and Bash scripts that allow the customer to install PHENOM. The creation and provisioning of this installer may take several days, as it is configured and tested to deploy the latest version of PHENOM. Skayl can provide support for the initial installation process.

==Setup Steps==
* Initialize a new environment with one of the following operating systems:
** Debian 11
** RHEL 8
** RHEL 9
* Create a `phenomadmin` user with “sudo” privileges.
* Extract the installer bundle in the `home/phenomadmin/` directory and navigate into the extracted directory.
* Execute the command `sudo bash vm_setup.sh`
** When prompted, enter the password for the database that will maintain PHENOM user data on this machine.
** Respond to any additional installer prompts. If you are unclear about one of them, contact the Skayl support team for guidance.
* If you experience errors, terminate the installation process, and send any error output to Skayl support.

==Installation Environment==
It is highly recommended that the environment be “bare” with only basic OS utilities installed and dedicated to serving only the PHENOM application. If this is not the case, Skayl may not be able to assist with configuration or debugging of packages required by PHENOM (e.g. Apache, MariaDB (mysql), etc.) which may be already present and configured or potentially used by other applications on the system.

Skayl cannot provide any support for the maintenance or configuration of the environment, whether internal virtualization environment or enterprise cloud provider (e.g. Microsoft Azure, AWS, etc.), that hosts the operating system running the PHENOM application or for the effects that environment has or requirements it imposes on the system running the PHENOM application.

Enterprise PHENOM

2025-08-07T13:56:30Z

Nathalie:

* [[PHENOM Installation]]
* [[PHENOM Updates]]
* [[PHENOM Network Diagrams | PHENOM Topology / Network Diagrams]]

PHENOM Installation Guide

2025-08-07T13:56:17Z

Nathalie: Nathalie moved page PHENOM Installation Guide to PHENOM Installation

#REDIRECT [[PHENOM Installation]]

PHENOM Installation

2025-08-07T13:56:17Z

Nathalie: Nathalie moved page PHENOM Installation Guide to PHENOM Installation

This page details the requirements for an on-site installation of the PHENOM application. PHENOM is a web-application reached by users via a web browser. As such, it requires the setup of a web-server along with supporting packages and application code in an environment from which it can reach its intended users.

While Skayl is always happy to assist our customers’ use of PHENOM, we are not able to provide comprehensive IT support for every enterprise environment in which the application may be deployed. As such, the customer is responsible for the setup, configuration, and maintenance of the internal IT infrastructure from which they decide to serve PHENOM to users. The sections below will enumerate the basic requirements of such setup but should not be considered an exhaustive listing of the potential IT support needs of a system hosting PHENOM.

Information about [[PHENOM Maintenance]] can be found here.

=Hardware Requirements=
It is recommended that the machine running PHENOM be configured with at least the following hardware:
* 4 CPU cores
* 32 GB of RAM
* 200 GB of drive space

=VM Deployment (Default)=
PHENOM can be provided fully installed and ready-to-run in a pre-packaged virtual machine to be hosted within the customer’s infrastructure. The machine can be delivered in one of the following formats, as exported by VirtualBox:

* OVF 0.9
* OVF 1.0
* OVF 2.0

The operating system on the provided virtual machine can be any of the following:

* Debian 11
* RHEL 8
* RHEL 9

It is the customer’s responsibility to ensure that they can import a VM of the selected format into their virtualization system and configure it to connect to any necessary networks. After installation, it is also the customer’s responsibility to keep the operating system of the installed virtual machine maintained and updated in accordance with their enterprise’s security and IT policies.

=Installer Deployment=
Skayl can provide an installer bundle and Bash scripts that allow the customer to install PHENOM. The creation and provisioning of this installer may take several days, as it is configured and tested to deploy the latest version of PHENOM. Skayl can provide support for the initial installation process.

==Setup Steps==
* Initialize a new environment with one of the following operating systems:
** Debian 11
** RHEL 8
** RHEL 9
* Create a `phenomadmin` user with “sudo” privileges.
* Extract the installer bundle in the `home/phenomadmin/` directory and navigate into the extracted directory.
* Execute the command `sudo bash vm_setup.sh`
** When prompted, enter the password for the database that will maintain PHENOM user data on this machine.
** Respond to any additional installer prompts. If you are unclear about one of them, contact the Skayl support team for guidance.
* If you experience errors, terminate the installation process, and send any error output to Skayl support.

==Installation Environment==
It is highly recommended that the environment be “bare” with only basic OS utilities installed and dedicated to serving only the PHENOM application. If this is not the case, Skayl may not be able to assist with configuration or debugging of packages required by PHENOM (e.g. Apache, MariaDB (mysql), etc.) which may be already present and configured or potentially used by other applications on the system.

Skayl cannot provide any support for the maintenance or configuration of the environment, whether internal virtualization environment or enterprise cloud provider (e.g. Microsoft Azure, AWS, etc.), that hosts the operating system running the PHENOM application or for the effects that environment has or requirements it imposes on the system running the PHENOM application.

Enterprise PHENOM

2025-08-07T13:56:05Z

Nathalie:

* [[PHENOM Installation Guide]]
* [[PHENOM Updates]]
* [[PHENOM Network Diagrams | PHENOM Topology / Network Diagrams]]

Virtual Machine Setup

2025-08-07T13:55:39Z

Nathalie: Nathalie moved page Virtual Machine Setup to PHENOM Installation Guide

#REDIRECT [[PHENOM Installation Guide]]

PHENOM Installation

2025-08-07T13:55:39Z

Nathalie: Nathalie moved page Virtual Machine Setup to PHENOM Installation Guide

This page details the requirements for an on-site installation of the PHENOM application. PHENOM is a web-application reached by users via a web browser. As such, it requires the setup of a web-server along with supporting packages and application code in an environment from which it can reach its intended users.

While Skayl is always happy to assist our customers’ use of PHENOM, we are not able to provide comprehensive IT support for every enterprise environment in which the application may be deployed. As such, the customer is responsible for the setup, configuration, and maintenance of the internal IT infrastructure from which they decide to serve PHENOM to users. The sections below will enumerate the basic requirements of such setup but should not be considered an exhaustive listing of the potential IT support needs of a system hosting PHENOM.

Information about [[PHENOM Maintenance]] can be found here.

=Hardware Requirements=
It is recommended that the machine running PHENOM be configured with at least the following hardware:
* 4 CPU cores
* 32 GB of RAM
* 200 GB of drive space

=VM Deployment (Default)=
PHENOM can be provided fully installed and ready-to-run in a pre-packaged virtual machine to be hosted within the customer’s infrastructure. The machine can be delivered in one of the following formats, as exported by VirtualBox:

* OVF 0.9
* OVF 1.0
* OVF 2.0

The operating system on the provided virtual machine can be any of the following:

* Debian 11
* RHEL 8
* RHEL 9

It is the customer’s responsibility to ensure that they can import a VM of the selected format into their virtualization system and configure it to connect to any necessary networks. After installation, it is also the customer’s responsibility to keep the operating system of the installed virtual machine maintained and updated in accordance with their enterprise’s security and IT policies.

=Installer Deployment=
Skayl can provide an installer bundle and Bash scripts that allow the customer to install PHENOM. The creation and provisioning of this installer may take several days, as it is configured and tested to deploy the latest version of PHENOM. Skayl can provide support for the initial installation process.

==Setup Steps==
* Initialize a new environment with one of the following operating systems:
** Debian 11
** RHEL 8
** RHEL 9
* Create a `phenomadmin` user with “sudo” privileges.
* Extract the installer bundle in the `home/phenomadmin/` directory and navigate into the extracted directory.
* Execute the command `sudo bash vm_setup.sh`
** When prompted, enter the password for the database that will maintain PHENOM user data on this machine.
** Respond to any additional installer prompts. If you are unclear about one of them, contact the Skayl support team for guidance.
* If you experience errors, terminate the installation process, and send any error output to Skayl support.

==Installation Environment==
It is highly recommended that the environment be “bare” with only basic OS utilities installed and dedicated to serving only the PHENOM application. If this is not the case, Skayl may not be able to assist with configuration or debugging of packages required by PHENOM (e.g. Apache, MariaDB (mysql), etc.) which may be already present and configured or potentially used by other applications on the system.

Skayl cannot provide any support for the maintenance or configuration of the environment, whether internal virtualization environment or enterprise cloud provider (e.g. Microsoft Azure, AWS, etc.), that hosts the operating system running the PHENOM application or for the effects that environment has or requirements it imposes on the system running the PHENOM application.

PHENOM Installation

2025-08-07T13:55:00Z

Nathalie:

This page details the requirements for an on-site installation of the PHENOM application. PHENOM is a web-application reached by users via a web browser. As such, it requires the setup of a web-server along with supporting packages and application code in an environment from which it can reach its intended users.

While Skayl is always happy to assist our customers’ use of PHENOM, we are not able to provide comprehensive IT support for every enterprise environment in which the application may be deployed. As such, the customer is responsible for the setup, configuration, and maintenance of the internal IT infrastructure from which they decide to serve PHENOM to users. The sections below will enumerate the basic requirements of such setup but should not be considered an exhaustive listing of the potential IT support needs of a system hosting PHENOM.

Information about [[PHENOM Maintenance]] can be found here.

=Hardware Requirements=
It is recommended that the machine running PHENOM be configured with at least the following hardware:
* 4 CPU cores
* 32 GB of RAM
* 200 GB of drive space

=VM Deployment (Default)=
PHENOM can be provided fully installed and ready-to-run in a pre-packaged virtual machine to be hosted within the customer’s infrastructure. The machine can be delivered in one of the following formats, as exported by VirtualBox:

* OVF 0.9
* OVF 1.0
* OVF 2.0

The operating system on the provided virtual machine can be any of the following:

* Debian 11
* RHEL 8
* RHEL 9

It is the customer’s responsibility to ensure that they can import a VM of the selected format into their virtualization system and configure it to connect to any necessary networks. After installation, it is also the customer’s responsibility to keep the operating system of the installed virtual machine maintained and updated in accordance with their enterprise’s security and IT policies.

=Installer Deployment=
Skayl can provide an installer bundle and Bash scripts that allow the customer to install PHENOM. The creation and provisioning of this installer may take several days, as it is configured and tested to deploy the latest version of PHENOM. Skayl can provide support for the initial installation process.

==Setup Steps==
* Initialize a new environment with one of the following operating systems:
** Debian 11
** RHEL 8
** RHEL 9
* Create a `phenomadmin` user with “sudo” privileges.
* Extract the installer bundle in the `home/phenomadmin/` directory and navigate into the extracted directory.
* Execute the command `sudo bash vm_setup.sh`
** When prompted, enter the password for the database that will maintain PHENOM user data on this machine.
** Respond to any additional installer prompts. If you are unclear about one of them, contact the Skayl support team for guidance.
* If you experience errors, terminate the installation process, and send any error output to Skayl support.

==Installation Environment==
It is highly recommended that the environment be “bare” with only basic OS utilities installed and dedicated to serving only the PHENOM application. If this is not the case, Skayl may not be able to assist with configuration or debugging of packages required by PHENOM (e.g. Apache, MariaDB (mysql), etc.) which may be already present and configured or potentially used by other applications on the system.

Skayl cannot provide any support for the maintenance or configuration of the environment, whether internal virtualization environment or enterprise cloud provider (e.g. Microsoft Azure, AWS, etc.), that hosts the operating system running the PHENOM application or for the effects that environment has or requirements it imposes on the system running the PHENOM application.

Projects and Models Management

2025-06-27T16:45:35Z

Nathalie: /* SDM Import Automatic Detection */

== 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.

[[File:Phenom-manage-project model structure1.png|600px|border]]

The following diagram depicts how a model can be part of multiple projects.

[[File:Phenom-manage-project model structure2.png|600px|border]]

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.

[[File:Phenom-manage-projects models list.png|500px|border]]

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.

[[File:Phenom-manage-active project.png|600px|border]]

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.

[[File:Phenom-manage-new project.png|600px|border]]

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.

[[File:Phenom-manage-switch-project-2.png|border|800x800px]]

== 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.

[[File:Phenom-manage-published model.png|600px|border]]

== 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.

[[File:Phenom-manage-model branching.png|600px|border]]

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.

[[File:Phenom-manage-model details2.png|border|800x800px]]

== Copy Project ==
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.
[[File:Manage - Copybtn.png|none|800px]]
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.
[[File:Manage - CopyCreate.png|none|800px]]

== 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.
[[File:Workflow-newModel.png|border|800px]]

[[File:Worlflow - CreatedSubmodel.png|border|300px]]

The user loads the model into an SDM_Editor project and begins to make the changes.

[[File:Worlflow - CreatingProject.png|border|800px]]

[[File:Workflow - SwitchProject.png|border|300px]]

Once the user has made the changes necessary to match a decided-upon standard, the user publishes a version v1 of his SDM model.

[[File:Workflow - PublishProject.png|border|300px]] [[File:Worklow - PublishedModel.png|border|300px]]

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.

[[File:Phenom-manage-example-chris-7.png|border|800px]]

=== 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.

[[File:Workflow - Davecreate project.png|border|800px]]

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.

[[File:Workflow - Dependencies.png|border|800px]]

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.

[[File:Phenom-manage-example-dave-4.png|border|800px]]

=== 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.

[[File:Workflow - DepFailure.png|border|800px]]

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.

[[File:Manage workflow - Final2.png|border|800px]]

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.

Integration Model to CinC Generation

2024-09-26T14:53:46Z

Nathalie: /* Add a TPM (OPTIONAL*) */

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.
[[File:Generate_-_CreateUoP.png|border|800x800px]]
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 .
[[File:Generate_-_CreateUoPInstance2.png|border|800x800px]]

== Create a Context ==
The context is a visual diagram of the interactions between a UoP and the configurable elements of CinC.
[[File:Generate - CreateContext.png|none|thumb|800px]]
# 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.
[[File:Generate_-_CreateMainProgram2.png|none|thumb|800x800px]]

== 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.'''

[[File:Generate - MainCreateTPM2.png|thumb|none|800px]]
# 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.
[[File:Generate_-_CinC.png|none|thumb|800x800px]]

Integration Model to CinC Generation

2024-08-26T15:18:46Z

Nathalie: /* Generate CINC */

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.
[[File:Generate_-_CreateUoP.png|border|800x800px]]
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 .
[[File:Generate_-_CreateUoPInstance2.png|border|800x800px]]

== Create a Context ==
The context is a visual diagram of the interactions between a UoP and the configurable elements of CinC.
[[File:Generate - CreateContext.png|none|thumb|800px]]
# 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.
[[File:Generate_-_CreateMainProgram2.png|none|thumb|800x800px]]

== Add a TPM (OPTIONAL*) ==
The transport protocol module is responsible for the serialization and deserialization of messages and their transport from one TPM to another or another system.

'''* PHENOM will generate a UDP TPM by default so this step may be skipped.'''
[[File:Generate - MainCreateTPM2.png|thumb|none|800px]]
# 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.
[[File:Generate_-_CinC.png|none|thumb|800x800px]]

Integration Model to CinC Generation

2024-08-26T15:17:58Z

Nathalie: /* Add a TPM (OPTIONAL*) */

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.
[[File:Generate_-_CreateUoP.png|border|800x800px]]
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 .
[[File:Generate_-_CreateUoPInstance2.png|border|800x800px]]

== Create a Context ==
The context is a visual diagram of the interactions between a UoP and the configurable elements of CinC.
[[File:Generate - CreateContext.png|none|thumb|800px]]
# 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.
[[File:Generate_-_CreateMainProgram2.png|none|thumb|800x800px]]

== Add a TPM (OPTIONAL*) ==
The transport protocol module is responsible for the serialization and deserialization of messages and their transport from one TPM to another or another system.

'''* PHENOM will generate a UDP TPM by default so this step may be skipped.'''
[[File:Generate - MainCreateTPM2.png|thumb|none|800px]]
# 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.
[[File:Generate_-_CinC.png|none|thumb|800x800px]]

Integration Model to CinC Generation

2024-08-26T15:16:09Z

Nathalie: /* Create a main */

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.
[[File:Generate_-_CreateUoP.png|border|800x800px]]
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 .
[[File:Generate_-_CreateUoPInstance2.png|border|800x800px]]

== Create a Context ==
The context is a visual diagram of the interactions between a UoP and the configurable elements of CinC.
[[File:Generate - CreateContext.png|none|thumb|800px]]
# 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.
[[File:Generate_-_CreateMainProgram2.png|none|thumb|800x800px]]

== Add a TPM (OPTIONAL*) ==
The transport protocol module is responsible for the serialization and deserialization of messages and their transport from one TPM to another or another system.

'''* Phenom will generate a UDP tpm by default so this step may be skipped.'''
[[File:Generate - MainCreateTPM2.png|thumb|none|800px]]
# 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.
[[File:Generate_-_CinC.png|none|thumb|800x800px]]

Integration Model to CinC Generation

2024-08-26T15:11:32Z

Nathalie: /* Create a UoP Instance */

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.
[[File:Generate_-_CreateUoP.png|border|800x800px]]
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 .
[[File:Generate_-_CreateUoPInstance2.png|border|800x800px]]

== Create a Context ==
The context is a visual diagram of the interactions between a UoP and the configurable elements of CinC.
[[File:Generate - CreateContext.png|none|thumb|800px]]
# 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.
[[File:Generate_-_CreateMainProgram2.png|none|thumb|800x800px]]

== Add a TPM (OPTIONAL*) ==
The transport protocol module is responsible for the serialization and deserialization of messages and their transport from one TPM to another or another system.

'''* Phenom will generate a UDP tpm by default so this step may be skipped.'''
[[File:Generate - MainCreateTPM2.png|thumb|none|800px]]
# 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.
[[File:Generate_-_CinC.png|none|thumb|800x800px]]

Integration Model to CinC Generation

2024-08-26T15:11:18Z

Nathalie: /* Create a UoP */

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.
[[File:Generate_-_CreateUoP.png|border|800x800px]]
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, A new UoP Instance can be created by selecting the corresponding option in the 'Create>Integration' dropdown and then saving after inputting the required data .
[[File:Generate_-_CreateUoPInstance2.png|none|thumb|800x800px]]

== Create a Context ==
The context is a visual diagram of the interactions between a UoP and the configurable elements of CinC.
[[File:Generate - CreateContext.png|none|thumb|800px]]
# 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.
[[File:Generate_-_CreateMainProgram2.png|none|thumb|800x800px]]

== Add a TPM (OPTIONAL*) ==
The transport protocol module is responsible for the serialization and deserialization of messages and their transport from one TPM to another or another system.

'''* Phenom will generate a UDP tpm by default so this step may be skipped.'''
[[File:Generate - MainCreateTPM2.png|thumb|none|800px]]
# 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.
[[File:Generate_-_CinC.png|none|thumb|800x800px]]

Integration Model to CinC Generation

2024-07-30T19:32:16Z

Nathalie:

THIS PAGE SHOULD TAKE THE USER THROUGH THE CREATION OF UOP INSTANCES, INTEGRATION MODEL, MAIN, AND CINC GENERATION.

== Sample Workflow ==
This sample workflow will lead the user to generate FACE 3 CinC after creating necessary Mains, UoP Instances, and UoPs.

Firstly, the user needs to 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.
[[File:Generate_-_CreateUoP.png|none|thumb|800x800px]]
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.

Similarly, A new UoP Instance can be created by selecting the corresponding option in the 'Create>Integration' dropdown and then saving after inputting the required data .
[[File:Generate_-_CreateUoPInstance2.png|none|thumb|800x800px]]
Next, the user needs to create a Main Program to be used during CinC. This is the Main Program that will house our UoP Instance and should be selected during creation.

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.
[[File:Generate_-_CreateMainProgram2.png|none|thumb|800x800px]]
Next the user needs to open the 'Generate' section and click on the CinC submenu.

The user should select 'CinC' as the artifact. For the generation config, the user should decide which changes to make depending on their setup. Only include CinC source if you have the required files. After setting up the CinC config, the user needs to now select their Mains and UoPs by using their checkboxes. Next, for each Main Program, the user will select an available CinC license. The user doesn't need to make any node selections to generate FACE 3 CinC but will here for demonstration.

Finally, click the 'Generate' button after setting up the config and selection to generate FACE 3.0 CinC and a .zip file will be created for download.
[[File:Generate_-_CinC.png|none|thumb|800x800px]]

== Code Generation ==
CinC generation targets a different type of element called a '''Main Program'''. These are created from the main 'CREATE' dropdown.
[[File:Imeditor_-_Codegen1.png|none|thumb|830x830px]]
Once your Main Program exists, you can associate UoP Instances to it so they become part of the generated code.
[[File:Imeditor_-_Codegen2.png|none|thumb|834x834px]]
Similarly, Main Programs can be placed in '''Processing Elements''' - but these are not incorporated into generation yet.

CinC Generation

2024-07-23T20:09:20Z

Nathalie: /* FACE 3 CinC */

{{DISPLAYTITLE: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

[[File:Cinc - Face3cinc.png|border|600x600px]]

== FACE 3 Mock UoPs ==
This options generates a FACE 3.0 aligned CinC with mock UoPs using the parameters provided by the user:
* Model Namespace: namespace that will be used throughout the generated code
* 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.

[[File:Cinc - Mockuop.png|border|600x600px]]

Projects and Models Management

2024-07-23T18:39:09Z

Nathalie: /* Sample Workflow */

== 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.

[[File:Phenom-manage-project model structure1.png|600px|border]]

The following diagram depicts how a model can be part of multiple projects.

[[File:Phenom-manage-project model structure2.png|600px|border]]

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.

[[File:Phenom-manage-projects models list.png|500px|border]]

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.

[[File:Phenom-manage-active project.png|600px|border]]

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.

[[File:Phenom-manage-new project.png|600px|border]]

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.

[[File:Phenom-manage-switch-project-2.png|border|800x800px]]

== 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.

[[File:Phenom-manage-published model.png|600px|border]]

== 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.

[[File:Phenom-manage-model branching.png|600px|border]]

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.

[[File:Phenom-manage-model details2.png|border|800x800px]]

== Copy Project ==
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.
[[File:Manage - Copybtn.png|none|800px]]
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.
[[File:Manage - CopyCreate.png|none|800px]]

== 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.
[[File:Workflow-newModel.png|border|800px]]

[[File:Worlflow - CreatedSubmodel.png|border|300px]]

The user loads the model into an SDM_Editor project and begins to make the changes.

[[File:Worlflow - CreatingProject.png|border|800px]]

[[File:Workflow - SwitchProject.png|border|300px]]

Once the user has made the changes necessary to match a decided-upon standard, the user publishes a version v1 of his SDM model.

[[File:Workflow - PublishProject.png|border|300px]] [[File:Worklow - PublishedModel.png|border|300px]]

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.

[[File:Phenom-manage-example-chris-7.png|border|800px]]

=== 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.

[[File:Workflow - Davecreate project.png|border|800px]]

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.

[[File:Workflow - Dependencies.png|border|800px]]

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.

[[File:Phenom-manage-example-dave-4.png|border|800px]]

=== 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.

[[File:Workflow - DepFailure.png|border|800px]]

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.

[[File:Manage workflow - Final2.png|border|800px]]

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.

Integration Model Editor

2024-07-23T18:31:08Z

Nathalie: /* Transport Nodes */

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'''.
[[File:Imeditor - UoPInstance.png|none|thumb|920x920px]]

== 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).

=== Transport Nodes ===
Transport nodes 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 Node Inspector on the right-hand side is used to give the nodes names, descriptions, and other data specific to its type.
[[File:Imeditor - Sidepanel.png|none|thumb|916x916px]]

*'''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 Node 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:
*: [[File:Imeditor - AutoTransform.png|none|200px]]
** Manual transform, which allows arbitrary assignment fields which will be parsed and incorporated into the generated transformation code:
*:[[File:Imeditor - ManualTransform.png|none|200px]]

* '''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:
[[File:Imeditor - Connection1.png|none|thumb|678x678px]]
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 node outputting BasicTypes, and sending it to an Endpoint expecting ComplexTypes:
[[File:Mismatched.png|none|thumb|511x511px]]

=== Ports ===
Ports facilitate the type that is used during context node connections and can be either input or output endpoints. Ports can accessed from the Node Inspector on the right-hand side when selecting a node 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 nodes 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.
[[File:Imeditor - PortDefault.png|none|thumb]]
b) Template type

Template type is determined by the user.
[[File:Imeditor - PortTemplated.png|none|thumb]]

== 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 node 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.
[[File:Imeditor - ComposedSwitch.png|none|thumb|786x786px]]

=== Composed Ports ===
From within the composed block context, the user may drag in any number of Composed In/Out port nodes. The composed ports nodes have only one respective input/output port and can be connected to the other context nodes. They need to be configured similarly to normal ports and require a Type and designated identifier (DataType or TemplateType).

These composed port nodes are identical to the ones utilized by a composed block instance.
[[File:Imeditor - trimmedComposedPort1.png|none|thumb|794x794px]]

=== 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 nodes and can be connected to any of the other nodes and even other composed block context instances. The ports represent the composed ports modeled in the actual composed block context.
[[File:Imeditor - ComposedInstance.png|none|thumb|831x831px]]

== Code Generation ==
CinC generation targets a different type of element called a '''Main Program'''. These are created from the main 'CREATE' dropdown.
[[File:Imeditor - Codegen1.png|none|thumb|830x830px]]
Once your Main Program exists, you can associate UoP Instances to it so they become part of the generated code.
[[File:Imeditor - Codegen2.png|none|thumb|834x834px]]

Similarly, Main Programs can be placed in '''Processing Elements''' - but these are not incorporated into generation yet.

Integration Model Editor

2024-07-23T18:25:38Z

Nathalie: /* Transport Nodes */

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'''.
[[File:Imeditor - UoPInstance.png|none|thumb|920x920px]]

== 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).

=== Transport Nodes ===
Transport nodes 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 Node Inspector on the right-hand side is used to give the nodes names, descriptions, and other data specific to its type.
[[File:Imeditor - Sidepanel.png|none|thumb|916x916px]]

*'''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 Node 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: test
[[File:Imeditor - AutoTransform.png|none|thumb|221x221px]]

** Manual transform, which allows arbitrary assignment fields which will be parsed and incorporated into the generated transformation code:
++[[File:Imeditor - ManualTransform.png|none|thumb|282x282px]]

* '''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:
[[File:Imeditor - Connection1.png|none|thumb|678x678px]]
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 node outputting BasicTypes, and sending it to an Endpoint expecting ComplexTypes:
[[File:Mismatched.png|none|thumb|511x511px]]

=== Ports ===
Ports facilitate the type that is used during context node connections and can be either input or output endpoints. Ports can accessed from the Node Inspector on the right-hand side when selecting a node 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 nodes 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.
[[File:Imeditor - PortDefault.png|none|thumb]]
b) Template type

Template type is determined by the user.
[[File:Imeditor - PortTemplated.png|none|thumb]]

== 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 node 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.
[[File:Imeditor - ComposedSwitch.png|none|thumb|786x786px]]

=== Composed Ports ===
From within the composed block context, the user may drag in any number of Composed In/Out port nodes. The composed ports nodes have only one respective input/output port and can be connected to the other context nodes. They need to be configured similarly to normal ports and require a Type and designated identifier (DataType or TemplateType).

These composed port nodes are identical to the ones utilized by a composed block instance.
[[File:Imeditor - trimmedComposedPort1.png|none|thumb|794x794px]]

=== 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 nodes and can be connected to any of the other nodes and even other composed block context instances. The ports represent the composed ports modeled in the actual composed block context.
[[File:Imeditor - ComposedInstance.png|none|thumb|831x831px]]

== Code Generation ==
CinC generation targets a different type of element called a '''Main Program'''. These are created from the main 'CREATE' dropdown.
[[File:Imeditor - Codegen1.png|none|thumb|830x830px]]
Once your Main Program exists, you can associate UoP Instances to it so they become part of the generated code.
[[File:Imeditor - Codegen2.png|none|thumb|834x834px]]

Similarly, Main Programs can be placed in '''Processing Elements''' - but these are not incorporated into generation yet.

Integration Model Editor

2024-07-23T18:14:47Z

Nathalie: /* Transport Nodes */

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'''.
[[File:Imeditor - UoPInstance.png|none|thumb|920x920px]]

== 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).

=== Transport Nodes ===
Transport nodes 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 Node Inspector on the right-hand side is used to give the nodes names, descriptions, and other data specific to its type.
[[File:Imeditor - Sidepanel.png|none|thumb|916x916px]]

*'''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 Node 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:
++[[File:Imeditor - AutoTransform.png|none|thumb|221x221px]]

** Manual transform, which allows arbitrary assignment fields which will be parsed and incorporated into the generated transformation code:
++[[File:Imeditor - ManualTransform.png|none|thumb|282x282px]]

* '''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:
[[File:Imeditor - Connection1.png|none|thumb|678x678px]]
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 node outputting BasicTypes, and sending it to an Endpoint expecting ComplexTypes:
[[File:Mismatched.png|none|thumb|511x511px]]

=== Ports ===
Ports facilitate the type that is used during context node connections and can be either input or output endpoints. Ports can accessed from the Node Inspector on the right-hand side when selecting a node 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 nodes border from within the context.

There are two views when editing a ports Type:

a) Default & Data Type

Data Type must be given from an existing view type from the model.
[[File:Imeditor - PortDefault.png|none|thumb]]
b) Templated & Template type

Template type must be typed into the input and is determined by the user.
[[File:Imeditor - PortTemplated.png|none|thumb]]

== 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 node 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.
[[File:Imeditor - ComposedSwitch.png|none|thumb|786x786px]]

=== Composed Ports ===
From within the composed block context, the user may drag in any number of Composed In/Out port nodes. The composed ports nodes have only one respective input/output port and can be connected to the other context nodes. They need to be configured similarly to normal ports and require a Type and designated identifier (DataType or TemplateType).

These composed port nodes are identical to the ones utilized by a composed block instance.
[[File:Imeditor - trimmedComposedPort1.png|none|thumb|794x794px]]

=== 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 nodes and can be connected to any of the other nodes and even other composed block context instances. The ports represent the composed ports modeled in the actual composed block context.
[[File:Imeditor - ComposedInstance.png|none|thumb|831x831px]]

== Code Generation ==
CinC generation targets a different type of element called a '''Main Program'''. These are created from the main 'CREATE' dropdown.
[[File:Imeditor - Codegen1.png|none|thumb|830x830px]]
Once your Main Program exists, you can associate UoP Instances to it so they become part of the generated code.
[[File:Imeditor - Codegen2.png|none|thumb|834x834px]]

Similarly, Main Programs can be placed in '''Processing Elements''' - but these are not incorporated into generation yet.

Integration Model Editor

2024-07-23T18:07:28Z

Nathalie: /* Transport Nodes */

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'''.
[[File:Imeditor - UoPInstance.png|none|thumb|920x920px]]

== 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).

=== Transport Nodes ===
Transport nodes 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 Node Inspector on the right-hand side is used to give the nodes names, descriptions, and other data specific to its type.
[[File:Imeditor - Sidepanel.png|none|thumb|916x916px]]

*'''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 Node 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:
[[File:Imeditor - AutoTransform.png|none|thumb|221x221px]]

** Manual transform, which allows arbitrary assignment fields which will be parsed and incorporated into the generated transformation code:
[[File:Imeditor - ManualTransform.png|none|thumb|282x282px]]

* '''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:
[[File:Imeditor - Connection1.png|none|thumb|678x678px]]
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 node outputting BasicTypes, and sending it to an Endpoint expecting ComplexTypes:
[[File:Mismatched.png|none|thumb|511x511px]]

=== Ports ===
Ports facilitate the type that is used during context node connections and can be either input or output endpoints. Ports can accessed from the Node Inspector on the right-hand side when selecting a node 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 nodes border from within the context.

There are two views when editing a ports Type:

a) Default & Data Type

Data Type must be given from an existing view type from the model.
[[File:Imeditor - PortDefault.png|none|thumb]]
b) Templated & Template type

Template type must be typed into the input and is determined by the user.
[[File:Imeditor - PortTemplated.png|none|thumb]]

== 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 node 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.
[[File:Imeditor - ComposedSwitch.png|none|thumb|786x786px]]

=== Composed Ports ===
From within the composed block context, the user may drag in any number of Composed In/Out port nodes. The composed ports nodes have only one respective input/output port and can be connected to the other context nodes. They need to be configured similarly to normal ports and require a Type and designated identifier (DataType or TemplateType).

These composed port nodes are identical to the ones utilized by a composed block instance.
[[File:Imeditor - trimmedComposedPort1.png|none|thumb|794x794px]]

=== 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 nodes and can be connected to any of the other nodes and even other composed block context instances. The ports represent the composed ports modeled in the actual composed block context.
[[File:Imeditor - ComposedInstance.png|none|thumb|831x831px]]

== Code Generation ==
CinC generation targets a different type of element called a '''Main Program'''. These are created from the main 'CREATE' dropdown.
[[File:Imeditor - Codegen1.png|none|thumb|830x830px]]
Once your Main Program exists, you can associate UoP Instances to it so they become part of the generated code.
[[File:Imeditor - Codegen2.png|none|thumb|834x834px]]

Similarly, Main Programs can be placed in '''Processing Elements''' - but these are not incorporated into generation yet.

Templates

2024-07-23T17:44:09Z

Nathalie: /* Available Node Types / Attributes */

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

[[File:Phenom-generate-templates.png|800px|border]]

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 <tr> tag, which means that code for a new table row will be generated for each measurement.

 
 
[[File:Phenom-generate-templates template syntax.png|none]]

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.

 
[[File:Phenom-generate-templates generated HTML.png|none]]

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:

[[File:Phenom-generate-templates node field extraction template.png|none]]

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.

{| class="wikitable"
|-
! 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
|
|
|
|
|
|
|
|
|-
|}

Projects and Models Management

2024-07-23T17:21:53Z

Nathalie: /* Copy Project */

== 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.

[[File:Phenom-manage-project model structure1.png|600px|border]]

The following diagram depicts how a model can be part of multiple projects.

[[File:Phenom-manage-project model structure2.png|600px|border]]

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.

[[File:Phenom-manage-projects models list.png|500px|border]]

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.

[[File:Phenom-manage-active project.png|600px|border]]

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.

[[File:Phenom-manage-new project.png|600px|border]]

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.

[[File:Phenom-manage-switch-project-2.png|border|800x800px]]

== 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.

[[File:Phenom-manage-published model.png|600px|border]]

== 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.

[[File:Phenom-manage-model branching.png|600px|border]]

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.

[[File:Phenom-manage-model details2.png|border|800x800px]]

== Copy Project ==
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 original 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.
[[File:Manage - Copybtn.png|none|800px]]
The create copy project screen is very similar to the project creation screen where the user needs to input a new name and description for the copied project. Additionally, the user needs to decide whether or not they want to copy all of the permissions that are currently selected from the source project to the copied project before saving.
[[File:Manage - CopyCreate.png|none|800px]]

== 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.

[[File:Workflow-newModel.png|border|600x600px]]

[[File:Worlflow - CreatedSubmodel.png|border|300x300px]]

The user loads the model into an SDM_Editor project and begins to make the changes.

[[File:Worlflow - CreatingProject.png|border|600x600px]]

[[File:Workflow - SwitchProject.png|border|300x300px]]

Once the user has made the changes necessary to match a decided-upon standard, the user publishes a version v1 of his SDM model.

[[File:Workflow - PublishProject.png|border|300x300px]]

[[File:Worklow - PublishedModel.png|border|300x300px]]

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.

[[File:Phenom-manage-example-chris-7.png|border|829x829px]]

=== 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.

[[File:Workflow - Davecreate project.png|border|600x600px]]

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.

[[File:Workflow - Dependencies.png|border|600x600px]]

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.

[[File:Phenom-manage-example-dave-4.png|border|812x812px]]

=== 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.

[[File:Workflow - DepFailure.png|border|600x600px]]

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.

[[File:Manage workflow - Final2.png|border|600x600px]]

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.

Tutorials

2024-07-23T17:13:17Z

Nathalie:

These hands-on tutorials walk users through different exercises to learn different aspects of PHENOM.

==Sample Workflows==
* [[Integration Model to CinC Generation]]

==Exercises==
* [[Developing an Entity Model]]
* [[Document Interfaces using PHENOM Portal]]

==Video Tutorials==
* [https://youtu.be/DLnrkxV-CyQ Introduction & Navigation]
* [https://youtu.be/sZw5jo3bnuE Importing Data Models]
* [https://youtu.be/b7g0xgm5_64 Sharing Data Models]
* [https://youtu.be/DwyibQqIsMQ Using Navigation Mode]
* [https://youtu.be/JLOMXk3jIEM The Diagram Tool]
* [https://youtu.be/nTfelA07Nzw Configuration Management]
* [https://youtu.be/J_Poq7v5_rE Subscription & User Management]
* [https://youtu.be/3MVA5TNSouM Expert Mode]
* [https://youtu.be/Fe-9O-T8c-g Tagging]

Tutorials

2024-07-23T17:13:03Z

Nathalie:

These hands-on tutorials walk users through different exercises to learn different aspects of PHENOM.

==Sample Workflows==
* Integration Model to CinC Generation

==Exercises==
* [[Developing an Entity Model]]
* [[Document Interfaces using PHENOM Portal]]

==Video Tutorials==
* [https://youtu.be/DLnrkxV-CyQ Introduction & Navigation]
* [https://youtu.be/sZw5jo3bnuE Importing Data Models]
* [https://youtu.be/b7g0xgm5_64 Sharing Data Models]
* [https://youtu.be/DwyibQqIsMQ Using Navigation Mode]
* [https://youtu.be/JLOMXk3jIEM The Diagram Tool]
* [https://youtu.be/nTfelA07Nzw Configuration Management]
* [https://youtu.be/J_Poq7v5_rE Subscription & User Management]
* [https://youtu.be/3MVA5TNSouM Expert Mode]
* [https://youtu.be/Fe-9O-T8c-g Tagging]

How-To Articles

2024-07-23T17:11:40Z

Nathalie:

#[[Login]]
#[[Dashboard]]
#[[Search Bar]]
#[[User Settings]]
#[[Basic Navigation]]
#[[Data Modeling]]
#[[Integration Modeling]]
#[[Generate]]
#[[Manage Models]]

How-To Articles

2024-07-23T17:10:21Z

Nathalie:

#[[Login]]
#[[Dashboard]]
#[[Search Bar]]
#[[User Settings]]
#[[Basic Navigation]]
#[[Data Modeling]]
#[[Integration Modeling]]
#[[Integration Modeling Workflow Example]]
#[[Generate]]
#[[Manage Models]]

Diagram

2024-07-09T14:49:52Z

Nathalie:

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 ===
[[File:Diagram overview.jpg|1000px|border]]

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 ===
[[File:Diagram top menu3.png|border]]

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 ===
[[File:Connector visibility2.png|border]]

A diagram can be used in one of two modes (1) Modeling (2) Projection:

'''Modeling mode'''

[[File:Diagram mode modeling.png|1000px|border]]

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'''

[[File:Diagram model projection.png|1000px|border]]

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 [[File:Diagram create composition.png|border]] icon to another object.

To create an association, click and drag the [[File:Diagram create association.png|border]] 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.
{| class="wikitable"
|+
!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.
|}
[[File:Diagram description.png|border]]

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 ==
[[File:Diagram management2.png|border]]

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'''

[[File:Load diagram.png|border]]

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.''

[[File:Uncommitted entities.png|border]]

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.

[[File:Diagram commit.png|border]]

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'''

[[File:Diagram path1.jpg|1000px|border]]

1. Select the Projected Characteristic. The selectable entities and associations are highlighted in green.

[[File:Diagram path2.jpg|1000px|border]]

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.

[[File:Diagram path3.jpg|1000px|border]]

3. To complete the path, the last hop have to be typed as an Observable.

Paths can be shown/hidden using the [[File:Diagram path eye.png|border]] icon. By using the show/hide eye icon repeatedly, the View paths will randomly change colors for convenience.

Permissions

2024-05-06T15:11:39Z

Nathalie:

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.

[[File:Perms5 2.png|frameless|636x636px]]

== 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 =
== 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.

[[File:Perms1.png|alt=Project Details Page Permissions Manager|frameless|1023x1023px]]

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.

== Assign Permissions to External Users ==
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.

[[File:Perms2.png|alt=Project Sharing Page|frameless|1027x1027px]]

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.

[[File:Perms3.png|alt=Accepting Perms Token|frameless|597x597px]]

This user, along with any other external users, will appear in the Permissions Manager under a separate External Users table.

[[File:Perms4.png|alt=Project Details with External Users Permissions|frameless|599x599px]]

== 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.

Permissions

2024-04-29T21:51:13Z

Nathalie:

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.

'''UPDATE IMAGE WITH OWNER COLUMN FILLED'''

[[File:Perms5.png|alt=Uncheckable Read Permissions Boxes|frameless|742x742px]]

== 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 make changes to projects and models themselves.'''

Having Admin permissions to a project or a model allows the user to change the metadata of the project or model and create inheriting projects or models. They can also set the permissions of other users (belonging to their own account) to this project or model up to Admin.

== 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, and to share it with users external to their account. Owner users can grant permissions up to Owner for internal users and Admin for external users.

= Assign Permissions =
== 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.

[[File:Perms1.png|alt=Project Details Page Permissions Manager|frameless|1023x1023px]]

To be able to share a Model, users need to have Admin or Owner permissions to it. The types of permissions users can grant depend on the the permissions they have to the model.
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 types of permissions users can grant depend on the the permissions they have to the project and its models. The type permissions granted for the project will be applied to all its models.

{| class="wikitable"
! Current User Permissions !! Target User Permissions Options
|-
| Read + Admin || Read, Admin
|-
| Read + Admin + Owner|| Read, Admin, Owner
|-
| Read + Write + Admin || Read, Write, Admin
|-
| Read + Write + Admin + Owner|| Read, Write, Admin, Owner
|}

== Assign Permissions to External Users ==
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.

[[File:Perms2.png|alt=Project Sharing Page|frameless|1027x1027px]]

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.

[[File:Perms3.png|alt=Accepting Perms Token|frameless|597x597px]]

This user, along with any other external users, will appear in the Permissions Manager under a separate External Users table.

[[File:Perms4.png|alt=Project Details with External Users Permissions|frameless|599x599px]]

== 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.

Permissions

2024-04-29T21:50:53Z

Nathalie:

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.

'''UPDATE IMAGE WITH OWNER COLUMN FILLED'''

[[File:Perms5.png|alt=Uncheckable Read Permissions Boxes|frameless|742x742px]]

== 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 make changes to projects and models themselves.'''

Having Admin permissions to a project or a model allows the user to change the metadata of the project or model and create inheriting projects or models. They can also set the permissions of other users (belonging to their own account) to this project or model up to Admin.

== 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, and to share it with users external to their account. Owner users can grant permissions up to Owner for internal users and Admin for external users.

= Assign Permissions =
== 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.

[[File:Perms1.png|alt=Project Details Page Permissions Manager|frameless|1023x1023px]]

To be able to share a Model, users need to have Admin or Owner permissions to it. The types of permissions users can grant depend on the the permissions they have to the model.
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 types of permissions users can grant depend on the the permissions they have to the project and its models. The type permissions granted for the project will be applied to all its models.

{| class="wikitable"
! Current User Permissions !! Target User Permissions Options
|-
| Read + Admin || Read, Admin
|-
| Read + Admin + Owner|| Read, Admin, Owner
|-
| Read + Write + Admin || Read, Write, Admin
|-
| Read + Write + Admin + Owner|| Read, Write, Admin, Owner
|}

== Assign Permissions to External Users ==
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.

[[File:Perms2.png|alt=Project Sharing Page|frameless|1027x1027px]]

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.

[[File:Perms3.png|alt=Accepting Perms Token|frameless|597x597px]]

This user, along with any other external users, will appear in the Permissions Manager under a separate External Users table.

[[File:Perms4.png|alt=Project Details with External Users Permissions|frameless|599x599px]]

== 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.

Permissions

2024-04-29T21:44:09Z

Nathalie:

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.

'''UPDATE IMAGE WITH OWNER COLUMN FILLED'''

[[File:Perms5.png|alt=Uncheckable Read Permissions Boxes|frameless|742x742px]]

== 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 make changes to projects and models themselves.'''

Having Admin permissions to a project or a model allows the user to change the metadata of the project or model and create inheriting projects or models. They can also set the permissions of other users (belonging to their own account) to this project or model up to Admin.

== 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, and to share it with users external to their account. Owner users can grant permissions up to Owner for internal users and Admin for external users.

= Assign Permissions =
== 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.

[[File:Perms1.png|alt=Project Details Page Permissions Manager|frameless|1023x1023px]]

To be able to share a Model, users need to have Admin or Owner permissions to it. The types of permissions users can grant depend on the the permissions they have to the model.
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 types of permissions users can grant depend on the the permissions they have to the project and its models. The type permissions granted for the project will be applied to all its models.

{| class="wikitable"
! Current User Permissions !! Target User Permissions Options
|-
| Read + Admin || Read, Admin
|-
| Read + Admin + Owner|| Read, Admin, Owner
|-
| Read + Write + Admin || Read, Write, Admin
|-
| Read + Write + Admin + Owner|| Read, Write, Admin, Owner
|}

== Assign Permissions to External Users ==
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.

[[File:Perms2.png|alt=Project Sharing Page|frameless|1027x1027px]]

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.

[[File:Perms3.png|alt=Accepting Perms Token|frameless|597x597px]]

This user, along with any other external users, will appear in the Permissions Manager under a separate External Users table.

[[File:Perms4.png|alt=Project Details with External Users Permissions|frameless|599x599px]]

== Account Admins ==
Account admins are able to see all the projects and models that exist on their account, and are able to assign permissions to those projects and models to any user on the same account up to Owner permissions. In case a project or model was shared to someone on an account using a Permissions Token, that account's Admins are only allowed to assign permissions to the project or model that someone on the account holds. '''WHAT?'''

Permissions

2024-04-29T21:33:21Z

Nathalie:

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.

'''UPDATE IMAGE WITH OWNER COLUMN FILLED'''

[[File:Perms5.png|alt=Uncheckable Read Permissions Boxes|frameless|742x742px]]

== 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 make changes to projects and models themselves.'''

Having Admin permissions to a project or a model allows the user to change the metadata of the project or model and create inheriting projects or models. They can also set the permissions of other users (belonging to their own account) to this project or model up to Admin.

== 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, and to share it with users external to their account. Owner users can grant permissions up to Owner for internal users and Admin for external users.

= Assign Permissions =
== Assign Permissions to a Model ==
Users are able to assign permissions to their models by using the Permission Manager on the Model Details pages. The table lists all the users from the same account as the current user.

'''NEED NEW SCREENSHOT'''

[[File:Perms1.png|alt=Project Details Page Permissions Manager|frameless|1023x1023px]]

To be able to share a model, the users need to have Admin or Owner permissions to it.

{| class="wikitable"
! Current User Permissions !! Target User Permissions Options
|-
| Read + Admin || Read, Admin
|-
| Read + Admin + Owner|| Read, Admin, Owner
|-
| Read + Write + Admin || Read, Write, Admin
|-
| Read + Write + Admin + Owner|| Read, Write, Admin, Owner
|}

== Assign Permissions to a Project or Model ==
Users are able to assign permissions to their projects and models by using the Permission Manager on the Project Details and Model Details pages. The table lists all the users from the same account as the current user.

[[File:Perms1.png|alt=Project Details Page Permissions Manager|frameless|1023x1023px]]

== Assign Permissions to External Users ==
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.

[[File:Perms2.png|alt=Project Sharing Page|frameless|1027x1027px]]

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.

[[File:Perms3.png|alt=Accepting Perms Token|frameless|597x597px]]

This user, along with any other external users, will appear in the Permissions Manager under a separate External Users table.

[[File:Perms4.png|alt=Project Details with External Users Permissions|frameless|599x599px]]

== Account Admins ==
Account admins are able to see all the projects and models that exist on their account, and are able to assign permissions to those projects and models to any user on the same account up to Owner permissions. In case a project or model was shared to someone on an account using a Permissions Token, that account's Admins are only allowed to assign permissions to the project or model that someone on the account holds. '''WHAT?'''