idb - transition (migration) - siemens · for importing idb data into a customer db (“updating”...

siemens.com/answersInternal / © Siemens AG 2015 All rights reserved.

iDB - Transition (Migration)

June 2015

Internal / © Siemens AG 2015 All rights reserved.

COMOS Plant Engineering Software

Industrial DatabaseBasic considerations

Base Objects, Attributes, Structures, Documents (Reports),

Interfaces, Engineering Projects, Customizing, Workflows

Need to be transferred from the existing DB to the iDB

A transition scenario needs to be provided to ensure a safe

operation of the plant and protecting the engineering know-how

An estimation regarding costs and time needs to be provided

June 2015



I – New Concept

Evaluation, reengineering and recreation of structures and functionalities

II – Transition (Migration) of Base Data

Transfer and adaption of available structures and functionalities to iDB

III – Transition (Migration) of Base and Engineering Data

Transfer and adaption of available structures and functionalities to iDB

Transfer and adaption of current engineering data

Industrial DatabaseTransition (Migration) – Three Scenarios

Individual decision depends on

Business Model (Owner/Operator /

Engineering)

Up-to-date-ness of available COMOS

version

Degree of modification / customization

CIS will provide appropriate

consulting and realization offers

prior to a possible Transition

(Migration)

June 2015



Industrial DatabaseTransition (Migration) – Workflow

• Analysis of the current data model, using a checklist

• Calculate effort

Analyze

• Offer a Transition (Migration) project

• Various options of customer involvements

Propose • Transition (Migration) based on selected Transition (Migration) concept

Migrate

June 2015



Industrial DatabaseTransition (Migration) – Concept

June 2015



Transition (Migration) ProcessIntermediate Step “DB Preparation”

Initial State at Customer

• Update cDB to current/released DB- &

Software version (minimum 10.1)

• Create Transition (Migration) DB

(MiDB): Copy of productive cDB

• Including min. 1 engineering

project (for testing purposes)

• Create SO1 transfer working layer (for

to be migrated data created during

Transition (Migration) phase)

June 2015



COMOS plugin for database-wide adjustments

MiDB SO1 opened in COMOS. Execute (&Undo) following functions:

1. Adapt iDB languages order

For compatibility with iDB, the order of languages in MiDB needs to be

rearranged (only if different from iDB)

First four languages order: German, English, French, Chinese

Additional existing languages added afterwards

Complete DB is evaluated (incl. engineering projects)

TIP: Execution can take longer time, because ALL DB tables containing

translations are evaluated and rearranged

Transition (Migration) ProcessTransition (Migration) – Step 1 ”Tool-based DB adjustments” – SQL Tool

June 2015





2. Adapt units of measurement system

For preventing naming collisions with iDB, customer units of

measurement in MiDB will be renamed with a Prefix “Z_”

Renaming will affect ALL uses of units of measurement (incl. units of

measurement system, local or global, AND checked-in units at

attributes)


June 2015





3. Adapt iDB SO1 project UIDs

For importing iDB data into a customer DB (“Updating” the customer

DB), the project UIDs of the base projects in both (cDB & iDB)

databases need to be matched

If they differ, executing this part of the tool will replace the base project

UID of MiDB with the base project UID of iDB

Important: Only project UID, NO object UIDs will be changed!


June 2015





4. Change DB to iDB/cDB “mode”

For software relevant objects, COMOS software identifies if database

is an iDB or a cDB

Executing this part of tool (after setting selection to iDB or cDB), iDB

or cDB “mode” can be set

For further steps in MiDB iDB mode is needed


June 2015



Updateability – Updating MiDB with iDB content

1. Execute COMOS Updateability software

2. Select MRA update DB (provided with installation package) and execute

update of database (without consolidating changes)

3. Select latest iDB service pack Update DB and execute update of

database (without consolidating changes)

Result:

cDB and iDB together in one database

iDB Database structure (Major released area, update collection layer,

customer released area) generated automatically

Complete cDB moved to customer released area automatically

MiDB prepared for future updates automatically

Transition (Migration) ProcessTransition (Migration) – Step 2 ”Import iDB into customer cDB (Updateability)”

June 2015



Toolbox

Includes multiple tools for Transition (Migration) of system data:

Drawing types/symbols, System standard tables, Standard table units, Report template objects, Copy/Move Cdevice (Properties),

Classification keys, execution of additional tools

Transition (Migration) ProcessTransition (Migration) – Step 3 ”Tool based Transition (Migration) of system data”

June 2015



Connector Tool

Automatically adapt customer DB connectors to corresponding new iDB

connectors. Based on mapping table (Rules file path), the tool executes

following actions:

1. Adaption of connector object names

2. Adaption of InternalConnection and CorrespondingConnector

3. Adaption of link information for attributes defined with link type via

connector

4. Adaption of access to connectors within symbol scripts (incl. symbol

scripts of standard tables)

Each action apart from 4 can be executed for base AND engineering projects

Transition (Migration) ProcessTransition (Migration) – Step 3 ”Tool based Transition (Migration) of system data”

June 2015



Mapping Tool (Tabs & Attributes)

All not software relevant objects & structures will NOT be integrated into iDB structures. They will just

be extended with mandatory iDB “Properties”

Hierarchical inheritance structures will be extended top down

Transition (Migration) ProcessTransition (Migration) – Step 4 ”Transition (Migration) of base data and customizing”

June 2015



All not software relevant objects & structures will NOT be

integrated into iDB structures. They will just be extended (tool

supported) with mandatory iDB “Properties”

Tabs / Attributes

Based on mappings a new (iDB) tab variant will be created in iDB tab

catalog (e.g. SYS Y00T00001), which will be referenced to cDB

object (in addition to original cDB tab)

New tab variant consists of: Mapped iDB attributes + not mapped cDB

attributes

After optional Transition (Migration) of engineering data (value

transfer) and final tests, the original cDB tab will be deleted


June 2015



Mapping Tool (Tabs & Attributes) – Re-use of configuration

Configuration of Mapping tool will be saved per object (in specific attribute @@MAP and mapping table)

Configuration of Mapping tool will be inherited, to not being forced to repeat mapping within hierarchical

inheritance structures

Configuration of Mapping tool can be reused for other tools (engineering data, scripts)


June 2015



Script Tool

1. Export of scripts in text files

2. Evaluation of text files and creation of strings for string DB

3. Adaption of strings (manual, positive/negative lists, automatic)


cDB

Tool 1

Exp./Imp.

Scripts in

files

Tool 2

Creation &

Exp./Imp.

of strings

String DB

(Findings DB)

Tool 3

Automtic

adaption of

strings

Mapping Lists

Positive Lists

Negative Lists

Manual

adaption of

strings

June 2015



Script Tool

4. Export of adaption into text files (Tool 2)

5. Re-import of text files/scripts into DB (Tool 1)


cDB

Tool 1

Exp./Imp.

Scripts in

files

Tool 2

Creation &

Exp./Imp.

of strings

String DB

(Findings DB)

Tool 3

Automtic

adaption of

strings

Mapping Lists

Positive Lists

Negative Lists

Manual

adaption of

strings

June 2015




Script tool 1 Script tool 2 & 3

June 2015



Transition (Migration) ProcessIntermediate Step “Transfer of base data (changed during Transition (Migration))”

If base project of productive cDB changed during Transition (Migration):

June 2015




• Migrate transfer working layers incl.

repetition of Steps 3&4


June 2015




• Migrate transfer working layers incl.

repetition of Steps 3&4

• Release transfer working layers


June 2015



Transition (Migration) ProcessOptional Step 5 “Transition (Migration) of engineering projects”

Variant 1 (in Transition (Migration) iDB):

• Adapt checked-in properties of

engineering project in Transition

(Migration) iDB

• Checked-in values from migrated

cDB tabs & attributes

• Connectors

• Classification keys

• Revisions

June 2015




Variant 1 (in Transition (Migration) iDB):

• Adapt checked-in properties of

engineering project in Transition

(Migration) iDB

• Checked-in values from migrated

cDB tabs & attributes

• Connectors

• Classification keys

• Revisions

• Switch Transition (Migration) iDB to

new productive iDB

June 2015




Variant 2 (in productive cDB):

• Transfer of Transition (Migration) DB

base project to productive cDB

• Re-link engineering projects

• Adapt engineering projects

June 2015




Variant 2 (in productive cDB):

• Transfer of Transition (Migration) DB

base project to productive cDB

• Re-link engineering projects

• Adapt engineering projects

• Delete cDB base project

• Switch productive cDB to iDB

June 2015



Smart Service CTCCOMOS Transition Check

• Analysis of the current data model, using a checklist

• Calculate effort

Analyze

• Offer a Transition (Migration) project

• Various options of customer involvements

Propose • Transition (Migration) based on selected Transition (Migration) concept

Migrate

June 2015




Based on the Transition (Migration) concepts, data model analysis, specifically prepared checklists, and

an overall review, the general Transition (Migration) capability of the customer data model will be

determined and effort estimation will be prepared.

1. Presentation of general Transition concept/steps (if not already done)

2. Installation of checklists & analysis tool

3. Execution of Analysis Tool (check for system relevant data in DB)

a) Prepare CSV export file

b) Discuss with customer, which database structures are in use

Filter csv file for relevant structures

c) Calculate objects count/effort

4. Completion of checklists (incl. export of checklist working layer when finished)

5. Prepare effort estimation (use/extend summary checklist)

6. Prepare customer documentation (use word document template)

June 2015



Analysis Tool (Step 3)

Tool to be used for analyzing customer database for objects (owning system

relevant tabs), which are customer relevant and are to be migrated.

Result of tool (object count / effort calculation) to be integrated in checklist for

effort estimation

1. If checkbox activated and date chosen, only objects younger than

comparison date are analyzed

2. Choose folder for result csv file

3. Choose if engineering projects should be searched for local base objects

4. “Execute Calculation”

The database is analyzed and all objects owning system relevant tabs

(based on mapping table) are collected.


June 2015



Analysis Tool (Step 3) - Result

In the result csv file (CTC_result.csv) following columns will be available:

PROJ_NAME: Name of COMOS project

OVERLAY_ID: ID of working overlay

CDEV_UID: SystemUID of COMOS object

CDEV_SYSFULL: SystemFullName of COMOS object

TABS_COUNT: Total amount of system relevant tabs at object

TABS_NEW: New system relevant tabs at object

TABS_CHECKEDIN: Only checked in system relevant tabs at object

TABS_INCL_LOCAL_ATT: System relevant tabs incl. local attributes at

object

ONLY_INCL_CHECKEDIN_TABS: “YES” if object only owns checked in

tabs

For more specified result, csv file should be opened in Excel and filtered for

relevant working overlays and/or Systemfullnames (which are in use or are to

be migrated).


June 2015



Checklists (in COMOS DB):

Checklists (Questions/Answers) to be filled out one by one in discussion

with customer.

Summary Checkpoint (J00 “Summary”) is completely linked to other

checklists and gives an overview of complete result.

Lists Export to be integrated in template documentation for customer

handover.
