Change Management - Engineering Base

Показать описание

Sequential engineering is a conventional method of plant engineering. Here, each discipline starts to work based on deliverables of previous disciplines. When there is a change in one discipline, this change and chain of consequent changes will be marked in next release of related documents and sent from one discipline to the other. Tracking of changes is limited to identify what is changed from last revision of received documents?
In parallel engineering, which provides more than 50% efficiency increase, all disciplines work on a same project data-model and documentation to complete it. Here, simple changes are consistent immediately in all disciplines, and advanced changes will go to a change workflow procedure. In parallel engineering, it is possible to see the changes from last revision, but also possible to manage versions and status of objects, see details of history, track changes in configurable lists, freeze diagrams against changes, work on parallel alternatives without changing the real data and create parallel scenarios. Each of these points will be explained in this video. Change management has two main categories: the first one is to get informed about the changes that happened before and track the history, and the second one is to suggest changes to happen to happen in future. In EB there are three main elements that changes can be viewed, Plant data model, data model representation on diagrams, and lists view of the data model. Diagrams are deliverables of the project and by each new revision of diagrams, all changes will be clouded with their old value as a tool-tip. This is done by revision management, either on the complete project or on a batch of selected diagrams. On the configurable list-views, each user can track the changes within his or her own scope and independent from document’s revisions. Next, is the object history in the plant data model. Here, the user can track the changes on an object to see who? changed what? when? and why? So, this was about tracking of what happened in the past. Now, how can change be suggested without modification of live data?
You have to remember that in a model-driven engineering platform, by default all changes are immediate, consistent, and persistent in all diagrams and reports of all disciplines. This is because the change, is happening on the live objects in the data model and diagrams and reports are just representing the data model actual status. Nonetheless, it is possible to go through a workflow of changes.
To protect a diagram against changes of its current status, it can be frozen. Freezing a diagram protects its existing objects, object’s attributes with values and connections. This diagram is still open for adding new objects and connection and add values to the attributes which are not frozen.
Whether frozen or not, modification of attributes also can be done in parallel alternative fields. Status of each attribute also can be modified and visualized with color identifications. The other situation is to modify objects. This can include object’s attributes or add or deleting objects. One possibility is to use object’s cases. Cases are alternative states of the same object. Their attributes can be case-dependent or can be inherited from the main object. One case can eventually be accepted and merged into the main object. The other possibility is to use special status attributes of objects. For example, if a frozen device should be deleted from the data model, its status can change to “To-be-deleted” so it can be deleted in the next iteration when it will be unfrozen. To learn about engineering workflows in various disciplines, watch next videos!