Healthcheck

Running a Project Healthcheck

There are certain characteristics that make some projects more useful than others. Projects defined using a clear, unambiguous structure are very well suited for automating integration. Their structure aligns them well for determining semantic equivalence with other systems. Some of these project qualities can be checked running relatively simple algorithms while others are far more complex. As additional project healthchecks are added to PHENOM, they can be run from this control panel.

To get to the healthchecks, navigate to the Data Model mode and select the Healthcheck tab. This will present you with a blank healthcheck page. Click on the "Run Healthcheck" button to initiate the tests. Please note, the tests may take a few minutes - a spinner icon indicates that PHENOM is working.

Once the tests are complete, the user will be presented with a summary of the test results. The summary will show the number of tests executed, the total number of issues found in the project, and the amount of time it took to complete the checks. In the middle, the summary reports the individual tests executed along with their results. In the example below, most of the entities in the project are unique, but there are many that do not have unique observables. There is a complete, color-coded listing of all the violations on the right-hand side of the page. This provide details about the errors to help identify and fix specific them in the project.

All test results can be downloaded as a CSV file by clicking on the "Download Report" button.

The project can be filtered by tags and be used in Healthcheck but please be aware that the healthcheck will ensure the project is a valid project. So if a set of nodes are excluded but they have dependencies, then the Healthcheck will add the nodes back in and they will appear in the health report.

Healthchecks

Entity Uniqueness

The Entity Uniqueness check determines if all of the entities in the project have a unique set of attributes and associations. Theoretically, if two things have the exact same set of attributes, then they are the same thing. While it may not seem to have any short-term consequences, entity uniqueness will be much more important when projects are analyzed for similarity and merge.

Attribute Uniqueness

Attribute Uniqueness checks to make sure that all entities have a set of unique attributes - that is, no two of its attributes can be of the same Entity type. How many positions does a vehicle have at once? Only one!

While that position may be measured a number of different ways, the truth is, that entity only has a single position.

Furthermore, when there are multiple attributes of the same type within an entity, the only way to discern any difference is by reading the attribute labels. These labels can be as misleading as they can be informative. Just like documentation in ICDs, sometimes a word choice that is clear to one person may be entirely ambiguous to another.

Observable Uniqueness

Similar to 'Attribute Uniqueness', Observable Uniqueness checks to make sure that all entities have a set of unique attributes - that is, no two of its attributes can be of the same Observable type. How many positions does a vehicle have at once? Only one!

While that position may be measured a number of different ways, the truth is, that entity only has a single position.

Furthermore, when there are multiple attributes of the same type within an entity, the only way to discern any difference is by reading the attribute labels. These labels can be as misleading as they can be informative. Just like documentation in ICDs, sometimes a word choice that is clear to one person may be entirely ambiguous to another.

Name Collisions

Although PHENOM will generally not allow users to create node with a name that is already in the project, there are ways in which name collisions may occur, including merging between branches or importing project content from external sources. Regardless of how they came about, any problematic name collisions (name collisions between nodes of the same type or having the same parent) will be reported here.

Circular Containment

While there are some legitimate cases for circular containment between entities and associations, a large number of these will be caused by modeling oversights. Such containments, as when entity A composes entity B, which in turn composes entity C, but entity C itself composes entity A, will be reported here.

Path Traceability

Although PHENOM's path builder ensures that only valid paths can be constructed, legacy paths from old imports may still find their way into a PHENOM project. Paths that cannot be legitimately traced through the project will be reported here. They will also be indicated with warnings on the View and View Attribute pages.

Placeholder Usage

In order to speed up modeling, PHENOM makes available a suite of placeholder nodes, including an observable, entities, and measurements. While the use of placeholders is convenient, projects containing placeholder values are not compliant. Four placeholder checks are part of the health report, indicating which view attribute paths contain placeholder entities, which paths project the placeholder observable, which entities type the placeholder observable, and which view attributes use a placeholder measurement.

Entities without an Identifier

Phenom encourages the addition of an Identifier attribute on every Entity (see the "Add Identifier attribute" checkbox on Create->Entity), to uniquely identify one Entity from the rest. While Entity uniqueness checks that each Entity has a unique set of Types, Entities without an Identifier checks that each Entity is Identifiable.

Deprecation Issues

Deprecating a node can affect other nodes either through paths or realizations. This section will report which nodes have been effected by deprecation and give an option to fix them. To fix deprecation issues, click on the wrench icon to bring up the UI. Currently, there are two different fixes available:

• Fixing composition types.
• Fixing path issues (for View Characteristics and Associated Entities)

Compositions Referencing Errors

Compositions that realize a deprecated observable will appear in this section.

Each composition is referencing the current deprecated Observable. A new observable can be selected from the dropdown list. By clicking SAVE, each composition will be updated with the new observable. * If a composition should not be updated at this time, you can deselect it by clicking the checkmark. * If a composition is highlighted, this means there is another layer of references to consider.

By changing the composition's observable, then the referencing view characteristic's measurement will need to change as well. In the top left, you will see the Current Measurement that each characteristic is pointing to. You can either set all of the measurements at once or you can set each measurement individually.'

Paths Errors

Both View Characteristics and Associated Entities may have path issues caused by deprecation. Each of these categories have their own section.

In the above example we have three different view characteristics called vsm_ID. Each of these have the same path that contain a deprecated node (UCSConfigurationResource). After creating a new path, click SAVE to update the path for each view characteristic. However if a characteristic should not be updated, you can deselect it by clicking the checkbox and fix it at a later time.

To see more about the Path builder, please see View Attribute.

Platform Enumerations with improperly matched Literals

This healthcheck captures issues with Platform Enumerations that don't match their realized Measurements, when comparing their Platform Enumeration Literals to the Measurement's Labels.

There are two categories that can currently show up on this report:

• 'Missing-realize': Enumerations will be marked as this if any of the PDM Literals do not have a 'REALIZES' relationship, or are realizing a Label with a different name.
• 'Mismatched': Enumerations will be marked as this if there aren't direct name matches between any of the PDM Literals and the Enumeration's traced LDM Labels, or if there are duplicate names.

These issues may not always indicate a problem with the Enumeration; there will be scenarios where a modeler may want to have specialized names in the Platform-level Enumeration that differ from the LDM Measurement Labels. Setting the realize relationship on LDM Literals indicates which Label a Literal represents.

Clicking on the links of each Enumeration found in this healthcheck will bring up the Platform Type editor, which you can use to manage them. For more details, go to Platform Type and Enumeration.

To see the Project Generation behavior PHENOM follows when generating Enumeration content, please see: Model & Artifact Generation

Views without Characteristics

This healthcheck captures Views without any child Characteristics. Platform Views are exported from Phenom as Views in FACE 2.1 and Templates/Queries in FACE 3.0. In both standards, the resultant element must not be empty.

Specialization Inconsistencies

Specialization Inconsistencies checks for inconsistencies in specializing Entities. Phenom's representation of specialization requires consistency in the attributes between the Entity specializing, and the Entity being specialized. If any of the attributes being specialized in Entity A are not present in Entity B, they will be present in this healthcheck.

FACE™ SDM Conformance

Use this healthcheck to monitor model conformance. As new versions of the FACE SDM are released, they will be enumerated in this healthcheck. Green check marks indicate matching conformance, yellow warning signs indicate disparities in expected SDM node content, and red X's indicate that content referenced by an SDM node could not be found in your model.

Platform Types with inappropriate type or Measurement

This check finds any discrepancies in Measurement realization. Among the following Platform Types Phenom supports, ("Boolean", "BoundedString", "Char", "CharArray", "Double", "Fixed", "Float", "IDLArray", "IDLSequence", "Long", "LongDouble", "LongLong", "Octet", "Short", "String", "ULong", "ULongLong", "UShort"), there are two additional supported types that are mutually exclusive with the previous list, to the measurements they can respectively realize: "IDLStruct", and "Enumeration". IDLStructs can only realize Measurements with multiple axes, and Enumerations can only realize Enumeration Measurements. All other types above cannot realize multi-axis or Enumeration Measurements.

Optional Characteristics

This check reports any characteristics marked "optional" in Phenom. Use this report to manage any characteristics marked this way.

Integration Context

If there are any issues with Integration Model content, those issues will be reported here. This includes checks for issues such as inconsistent data types, missing message ports, and endpoints with multiple connections.

Conversion Errors

Of the logical conversion elements Phenom supports, ("MeasurementConversion", "MeasurementSystemConversion", "CoordinateSystemConversion"), if any contain an invalid equation, Phenom will report these here.

Bounds Issues

There are many elements Phenom supports that may have lower or upper bounds. Of these elements, if any have invalid bounds, (for example - lower bound is greater than upper bound), Phenom will report these elements here.

Nested View Issues

This health check finds all privately scoped nested views used in more than one perspective or used within more than one view family.

Composed Block Instance Issues

This health check traces through the node connection and compares the Composed Block Instance with the connected block node, and searches for mismatched data types or inconsistent template types.