UNICOS
CONSISTENT IMPORT/EXPORT
Agenda

Present status of prototype for new import

Verification of addresses during check

Non standard import files

Role of the delete command

Use of value archive

Future support of ‘exotic’ features

Public interfaces of the import library
Prototype for new import
… can import devices by name

ADD new & UPDATE existing devices

SHIFT device indices
… can detect & report conflicts (using device index)

DELETED devices

RENAMED devices
… can automatically clean-up (delete) obsolete devices

Delete remaining devices that are not in import file

Only works with full file, manual confirmation necessary
Snapshot for testing is available in Nexus
Limitations of the prototype
No automatic renaming of devices

Reason: Cannot distinguish rename from delete & recreate

Manual resolving required
Limited automatic deletion of devices

Reason: Cannot distinguish rename from delete & recreate

Manual resolving required
No detection of address shifts

Cannot check if a new address is used by another device

Reason: Device implementation provides no such function
Verify addresses during check
Adding or deleting a single device can cause address shifts of all other
devices (even those of other types or other applications)
Device Type 1
Device Type 2
X (newly add device)
L (shifted address)
A (shifted index & address)
M (shifted address)
B (shifted index & address)
N (shifted address)
C (shifted index & address)
O (shifted address)

Full import of complete file works fine

Partial import: we may not be able to detect corrupt files

Multi application: Consistent treatment would require batch import
Possible solution:

Extend device packages to be able to report output addresses
from import file (CPC6 is already capable, other packages ?)

This would enable us to check addresses prior to import
Non standard import files (PIC,WIC)
Custom import file format (used to reference sub-devices)
DEVICE TYPE
DEVICE INDEX DEVICE NAME
Explanation
CIW
1
CIP.UA23.AL2
“Real” device, is a DP
CIW
1
A
“Sub-device, is part of DP
CIW
1
B
“Sub-device , is part of DP
CIW
1
C
“Sub-device , is part DP
Problem: New import cannot be applied here because:

Device A, B, C are no UNICOS devices

Device index is not unique, no detection of index shifts
Are there more cases like this ?
Role of the delete command
Keyword Delete in import file

It is the only way to delete devices in UNICOS

Single devices are being referenced by index, this
can be very misleading when using import by name

There is only a delete but no rename keyword,
which would be needed as well

Developers need to comment/uncomment/edit the
DELETE statement to achieve what they want
Proposal: purely declarative import file

Import file contains devices and no commands

Add an expert panel that allows to delete and rename
devices
Use of Value Archive (file-based)
UNICOS contains lots of complicated code related to ValArch

Eg. Checks if devices fit into an archive, etc

Not even sure that it works correctly!

The Valarch code is interleaved into the import libraries…
How much of it is still needed after migration to RDB?

Parallel archiving used only marginally and temporarily
(to assure archive-depth of 1 year in CRYO, for instance)

Do we need to maintain all the diagnostics/configuration
facilities (we could use the WinCC OA built-ins)

How could we deal with development/testing?
Proposal: Make the use of ValueArchive deprecated,
with more “manual” configuration
Future support of ‘exotic’ features
Keyword PLCCONFIG_extended

Used to import PLC communication?

Is it still used?

Should it be still supported?
Keywords SystemAlarm and _UnSystemAlarm

In CPC system alarms are created with front-end

Are keywords still used?

Should they still be supported?
Interfaces of unImportDevice library

Right now all functions in the import library are public

This makes it very hard to refactor the code, because it is
not obvious which functions are being used by
application packages and which not.

Proposal: Specify a well defined public interface,
so that we gain more freedom to refactor the code.

If this should be done, we need to know which functions
of the library are being used by external packages.
That’s all folks
“In the middle of difficulty lies opportunity” - Albert Einstein