kbss-cvut / fta-fmea-ui Goto Github PK

The quick-fix comments out the profile based solution.
Restore the profile based solution and make sure that the avic deployment works properly.

Merge SOURCE component into TARGET component with all functions and failure modes from SOURCE component.
Additional Requirements

• if SOURCE component have a parent component it should be the same component as the parent of the TARGET component

@blcham @kostobog @LaChope

User should be able to load reliability data regarding component's functions.
The accepted format for the import is a csv with the following columns:

• component iri
• function iri
• time to failure/probability of failure

The solution should also accept import from an ontology file

Given a failure mode with name "fm". Currently the name pattern is "function fails as fm". Change the pattern to be just "fm".

When there are many required functions with longer names the submit button for the function form is rendered off screen.
Make sure that the button's position is rendered on screen.

A/C:

• runs at https://kbss.felk.cvut.cz/fta-fmea-demo
• uses repository with Id fta-fmea-demo
• should be possible to register

The link https://kbss.felk.cvut.cz/fta-fmea-demo/fta/instance-1287330450 does not work (I get 404 but instead it should redirect me to login page).

See how termit-ui works :).

In the Dashboard, when a System/FTA/FMEA artifact is just renamed. When the form is visited right after the first rename the form shows the old name (the name before the first rename).

Fix form to show the current name of the renamed artifact.

Calculation of probability of FTA events does not consider that some of the events in the FTA are the same event, i.e. there are events in the tree which are not independent.

To fix this use an existing library (https://github.com/mbarrere/mpmcs4fta) to calculate probability in a fault tree.

In the form for creating and editing functions in the System diagram add an editable list which contains failure modes that impair the function.
The form should allow to add and remove failure modes from a list.
Each failure mode in the list of failure modes should show in parenthesis the label of the component of the failure mode.

The algorithm generating FTA from a system description should not generate new failure modes.

For more details see GD

Reproduce:

1. Log in
2. Open new tab -> for example: link
3. Click Back icon

Add an editable Note column in the FMEA table.
The form for editing the note should have one multiline text field.
In the data model the note is associated with a row of the FMEA.

Relax the restriction to specify labels with at least 3 characters.
This holds for all model elements

• system
• component
• function
• failure mode
• event (in FTA editor)

Visiting an FMEA (navigating from dashboard, refreshing a FMEA page) causes the its rows to grow in number. It seams that the number of rows doubles on each visit.

See it here, suggest changes:
#36

Acceptance criteria

• when opening a system the user should see the tree based system editor and an option to change the diagram based editor.
• the tree visualizes the component partonomy
• components which are parts of the same whole should be ordered alphabetically
• on component edit use the same component editor widget used in the diagram based editor

Create a diagram component that can visualize the behavioral description of the edited system.

Diagram Element Specification

Nodes - the nodes in the diagram are behaviors, the label of the node is the name of the behavior. Complex behaviors should be rendered with a corresponding logic gate (AND or OR).

• functions - green boxes
• failure modes - red round corner box
• failure mode cause - yellow round corner box,
• mitigation - blue boxes

Edges - there are three types of edges

• requires - label requires, has arrow on targets end, connects to target node not to its gate.
• impairs - label impairs, has arrow on targets end, connects to target node not to its gate.
• part of - no label, has no arrow on targets end, connects to gate of target node.

Interaction with the Diagram

The diagram is read only.
Add a layout button to allow user to layout the diagram automatically (if supported by the library).
User should be able to manipulate the position of diagram nodes by dragging them.
User should be able to export an image from the diagram.

Navigation

The diagram should be accessible trough a link in the system editor.
In the behavioral diagram user should be able to navigate back to the system editor.

Within the deployment https://kbss.felk.cvut.cz/fta-fmea-demo/, create examples of FTA/FMEA related to paper. Describe them in the README.

A/C;

• create examples within the tool with generated FTA as well
• describe it in a very simple way in relevant readme file (as Live Example 3)

A/C:

• both UI and backend has their own docker packages published on github, which is triggered by github actions on commit to master/main
• there is docker-compose file in this repository which orchestrates backend and frontend together

Inspiration:

• csat-planning
• SPipes Editor
• Termit UI
• Termit docker

In System editor when editing failure modes of component as well as when creating failure modes for components the user should be able to specify a Failure Mode Type with two possible options:

• Failure Mode
• Failure Mode Cause

Client Requirements

• When the user selects Failure Mode option, the original form of failure modes should be shown.
• When the user selects Failure Mode Cause option, the form should reduced by removing the behavior type and the required failure modes fields. If the edited failure mode has specified values for child and required failure modes, the user should be notified that they will be removed from the edited failure mode. If the user accepts the change the application should remove child and required failure modes from the edited failure mode and set its behavior type to basic.

The user interface should look as shown in the screenshot below.

Server Requirements

• model - Implement the Failure Mode Type in Failure Mode entity similar to Behavior Type.
• FTA generation - do not generate fault events for Failure Modes with a Failure Mode Cause value for the Failure Mode Type property.

Fix the generation of FMEA table from a fault tree. The procedure processes each tree path, i.e. fault events from the leaf failure event (e.g. basic failure event) to root failure event in the FT. The procedure should first select the Function and then derive Component, Failure Mode and local, final and intermediate effects.

• select Function - select function (F) in a function failure (FF) fault event closest to the path's leaf
• select Component - select the component (C) of the selected function F
• select Failure Mode - select the Failure Mode (FM) of the Fault Event which is a direct child of the FF Fault Event . If there is no child fault event or if the fault event is not a manifestation of a failure mode leave the failure mode column empty.
• select Cause - select the FailureModeCause (FMC) is either the direct required FailureModeCause of the selected FM or the direct FailureModeCause impairing the selected F. Each possible cause FMC that can be selected should be used in a new FMEA row.
• select Local Effect - the local effect (LE) should be a direct parent of the FF fault event and it should be a failure of a function which is different from function F and is in component C. If there is no such fault event leave the column empty.
• select Final Effect (no changes in requirements) - select the final effect EF as the root fault event in the path
• select Intermediate Effects - all fault events in the same order as events in the path between the LE and EF excluding both LE and EF. If LE is not selected/empty start from FF instead.

Finally make sure that the each generated row in the table is unique.

In the component form in the system editor, user should no be able to select or see failure mode causes in:

• failure modes field in the functions section
• parts in failure modes section

@blcham @ahmadjana

It seems that some commits in branch feature/function-parts are not merged in main.
Commits:
[Feature #17] Allow to add existing function to a component Matej Kulich 2/9/2022 4:25 PM d36b9de
[Feature #15 and #17] Add existing function to a component, fix bug with bad assign Matej Kulich 2/3/2022 1:31 PM 14d0f02
[Feature #11] Add required functions highlighting Matej Kulich 1/27/2022 7:01 PM df2b1ca
[ Feature #12 ] Add managing function parts Matej Kulich 1/25/2022 9:30 PM 4745802

Check if the changes in those commits are implemented in main.
If changes are not found in main, merge and resolve conflicts for the changes from those commits into main.
If changes are found in main: specify the commits in main where the changes are implemented.

The UI does not fetch data from the backend after the user clicks several times on and off a component in the system editor.

Update the algorithm from issue #5. Given a function the algorithm transforms the tree of its required functions (Function.requiredFunctions) into a fault tree. The algorithm should be updated to handle changes in the behavioral model introduced in ticket fta-fmea/Normalize the Behavior Model #8

Implementation Notes:
Compared to the previous version of the algorithm functions can fail because of their parts. Here is a summary of all sources of fault events:

• Function.failureModes - fault events which are manifestations of failure modes impairing the function
  • Label pattern for new fault events of this type - "$Function fails b/c of $FailureMode"
• Function.requiredFunctions - fault events of the function's required functions
  • Label pattern for new fault events of this type - "$RequiredFunction fails"
• Function.parts - fault events of the function's parts (different from required functions). When generating these type of fault events the Function.behaviorType should be taken into account, see below:
  • for OR functions generate AND fault events where the child fault events are the fault events of the child functions.
  • for AND functions generate OR fault events where the child fault events are the fault events of the child functions.
  • Label pattern for new fault events of this type - "$Function fails b/c its parts fail"

Compared to the previous version the new version of the algorithm should process failure mode parts. Generate fault events as follows:

• OR failure modes into OR fault events where the child fault events are manifestations of the child failure modes
• AND failure modes into AND fault events where the child fault events are manifestations of the child failure modes

The diagram below shows an example of the transformation. Note that the fault event labels follow the label patterns defined above.

Refactor the 'hasComponent 'relationship between System and component from
http://onto.fel.cvut.cz/ontologies/fta-fmea-application/hasComponent
to
http://onto.fel.cvut.cz/ontologies/fta-fmea-application/hasPartComponent

Provide update query to do this refactoring.
Apply refactoring to fta-fmea-demo repository after issue #53 is merged into main.
Apply refactoring to fta-fmea-cape repository after issue #53 is merged into avic.

Make the Mitigation column in the FMEA table editable.
User should be able to create, edit and delete mitigations on each row.
One table row has at most one mitigation and one mitigation is associated with at most one row.

The mitigation form should include the following fields:

• title - one line text (use model Mitigation.name)
• description - multiline text (use model Mitigation.description)
• (C) failure mode: user can select the cause or failure mode of the same row as the edited mitigation (use model Mitigation.impairedBehaviors)

• In the component form add a new list of Mitigation behaviors under failure modes form.
• Extend the failure modes form in the component editor to allow users to specify Mitigations which impair the failure mode.

Currently only new functions and failure modes can be added to a component. Existing failure modes and components are not cannot be added to a component.
Acceptance Criteria:

• users should be able to add existing functions and or failure modes to a component.

In some cases data of an organization cannot be public and thus we should disable registration of users in such case.

A/C:

• there is a configuration for deployment with appopriate flag (e.g. disableRegister)
• If enabled:
  • UI does not show link to register
  • backend does not have the REST endpoint to register
  • the register endpoint is allowed only for registered users with the ADMIN role.

To reproduce the issue:

1. Open the dashboard page
2. Create a system with a long name with no spaces, e.g. "POWER_SYSTEM_KM_Main AC power supply _supply AC from ENG's".
3. If the problem does not occur refresh the page

Issue description:
The created system label moves the controls of the system widget. The user cannot access system widget actoins available under the three dots, i.e. delete and rename

Acceptance criteria

• long names with no spaces won't hide the system widget controls
• the name of the system is partially hidden the full label should be visible on mouse hover

Generate Fault Tree Model based on the functional dependencies (FD) network defined trough the field Function.requiredFunctions.

Acceptance criteria:

• implement the function in service package. May be it is ok to be in FaultTreeRepositoryService.
• the method takes a function IRI (URI) and a name for the new FTA and creates a new fault tree
• Implementaion notes:
  • make sure that each function in the FD network has a failure mode. Generate a failure mode for each function in the FD network.
  • each function in the FD network is transformed into a FaultEvent. The EventEvent should be associated with a failure mode of the function.
  • each dependency relation in the FD network is transformed to a fault tree edge, i.e. Function.requiredFunctions should be transformed to FaultEvent.children.
  • Make all gates "OR Gates". Note: The user will have to change the gate as necessary as we do not have sufficient information to decide which is the correct gate type.
  • Generated fault tree should show in the dashboard (main application page) and it should be possible to open and edit them in the UI.
• implement REST
• implement UI generate call the service for a selected function. For now it is sufficient to enable the generation of FTA from the Function editor.
  The UI should ask the user about the name of the Fault Tree.

As a user, I would like to use autocomplete tree component to select required function. The tree itself should be composed of partonomy of components where leaf nodes are functions to select.

Additional notes:
Use inteligent tree component for than. See termit how inteligent tree component is used.

Reproduction:

1. Create new function (Do not refresh page.)
2. Add this newly created function to required functions
3. Click update

Extend the form ComponentFunctionEdit (system-editor/component-form/function-form) to allow the user to specify whether the function is atomic or has parts (ATOMIC, or AND or OR) and if the function has parts to select function parts from a list of functions.

• add a single choice component which will allow the user to specify whether the function is an "AND", "OR" or "ATOMIC" one.
  • label of field is "Function complexity"
  • default value is ATOMIC
  • if there are selected function parts and the user selects ATOMIC and submits the form open a dialog asking the user if they want to unselect all functions selected as parts or to abort the submit and change ATOMIC to AND or OR.
• add a multi-select component which will allow the user to select one or more functions that represent the edited functions' parts.
  • component should be conditionally visible if the "Function complexity" field has the value "AND" or "OR"
  • Functions in the list should be rendered the same way as in the required function list, e.g. label of function (label of its component). Function entries shold be color coded, the same way as in the list for selecting required functions. Render function with gray color in the list if they contain the edited function in the transitive closure of the part-of relation.
  • The list should exclude the currently edited function

Some functions cannot be added as required function in the system editor. The server cannot parse the JsonLd sent by the client.

ERROR o.a.c.c.C.[.[.[.[dispatcherServlet] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is cz.cvut.kbss.jsonld.exception.JsonLdDeserializationException: Encountered multiple values of property http://onto.fel.cvut.cz/ontologies/fta-fmea-application/hasComponent, which is mapped to a singular attribute private cz.cvut.kbss.analysis.model.Component cz.cvut.kbss.analysis.model.Behavior.component]

The bug can be reproduced in system "test 1" in fta-fmea-demo add function 4 as required to function 1 in component 1.

Extend the form to edit components in the system editor. The form should allow to create one or more failure modes for the edited component. The user should be able to edit each failure mode by changing its name and specifying whether it is "atomic", "and or "or" behavior type and then allow to specify its parts. The user should be able to delete the failure mode from the list.

Description

In the component's behavior forms, in the system component form, the user can edit:

1. required functions of a function
2. parts of a function
3. failure modes which impair a function
4. required failure modes of a failure mode
5. parts of a failure mode

In each of the mentioned edit use-case the user is presented a list with behaviors from which to choose. The user should be able to distinguish behaviors which are transitively related to the edited one and other behaviors in the list.

Acceptance Criteria:

Distinguish the following behaviors from other behaviors in the lists specified above

1. the indirectly required functions of the edited function
2. the indirect function parts of the edited function
3. the failure modes which indirectly impair the edited function
4. the indirectly required failure modes of the edited failure mode
5. the indirect failure mode parts of the edited failure mode

Implementation Notes

• in the backend implement a rest api method which for a given function retrieves all functions that transitively require the input function.
• use the new backend rest api method to color code the list of functions. Functions which require the edited function transitively should be gray. Other functions remain black.

Behavior lists are not updated when a behavior is changed in the component editor. This is true for all lists:

• functions' required functions

• functions' parts - not sure but it is possible that it has the same error.

• functions' failure modes

• failure modes' parts

• failure modes' required failure modes

• Create a new property in the ontology representing relationship between system and its components: http://onto.fel.cvut.cz/ontologies/fta-fmea-application/hasPartComponent

• Use the new property in the System model objects both on client and server side.

See fta-fmea-demo deployment

Refactor function model on the client side so that it can be used to access components similar to the failure mode model.
Consider creating common behavior model containing common properties and relation which is then extended by the function and failure mode models, see also discussion at pullrequest#51.

We would like to use a tree component to allow filter functions based on partonomy. For that intelligent tree select can be used:
https://github.com/lecbyjak/intelligent-tree-select

To reproduce the issue login in https://kbss.felk.cvut.cz/fta-fmea-avic/ and open system MAIN AC SUPPLY (https://kbss.felk.cvut.cz/fta-fmea-avic/system/instance881277938).

The issue can be observed for example in component ZDE1. The component is associated with failure mode F1_-fm but the failure mode is not visible in the component editor form. Here some more examples of the same issue ZDE2 and F3_-fm; AC_R_BUS and F4_2-fm; and AC_L_BUS and F2_2-fm.

As a user, I want to add functions and its required functions.

Acceptance criteria:

• CRUD for functions and their required functions is implemented
• To search function, the user should see with function name its component name

• add short info about
• put link to demo (kbss/fta-fmea-demo)
  • say something about free registration
• put link to backend