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)  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 Device Type 1Device 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)

Non standard import files (PIC,WIC) Custom import file format (used to reference sub-devices) 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 ? DEVICE TYPEDEVICE INDEXDEVICE NAMEExplanation CIW 1CIP.UA23.AL2 “Real” device, is a DP CIW 1A “Sub-device, is part of DP CIW 1B “Sub-device, is part of DP CIW 1C “Sub-device, is part DP

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