Guidance Notes for DeltaV Configuration … · DeltaV Configuration Management between Multiple...

Guidance Notes for

DeltaV Configuration Management between Multiple

Systems

A vital piece of the jigsaw

DeltaV Configuration Management between Multiple Systems of 14 Version: 1.0 File Name: INT-DVMDS-001.docx For Information Only

1. DeltaV Configuration Management between Multiple Systems

1.1 Synopsis

This document will provide an introduction to the problems encountered in controlling software components within multiple Emerson DeltaV process control systems (PCS) and will offer guidance on minimising the inherent risks. The document discusses the importance of tight management of configuration in a multiple-platform development environment, emphasises the importance of a Configuration Management Plan, and introduces the idea of gatekeepers to police configuration changes. It highlights some of the specific challenges of configuration management for DeltaV systems and suggests some solutions based on Intuitive’s many years of project experience. The guidance provided is equally applicable to many other systems with multiple software components.

1.2 Introduction

The majority, if not all modern industrial Process Control Systems (PCS) provide a hierarchal software structure that consists of many individually complex, self-contained and inter-dependent component software modules (i.e. building blocks). With the introduction of programming standards such as IEC61131 Part 3 – Programmable Controllers: Programming Languages and ISA-88.01 (S88) - Batch Control Part 1: Models and Terminology re-enforce the use of modular software building blocks that are integrated within the overall process control system. The design, configuration and testing of each software module within the overall PCS software hierarchy requires management in order to effectively control the overall software scope. For example: a process plant would typically standardise the type and functionality of all isolation valves, pumps, motors etc. and would therefore use a common module (software block) as the starting point for a specific module instance. If the modules are class based then they retain a link to the parent module class software. Therefore if the module class is modified the change would affect all associated instances. It is therefore imperative when modifying and managing software to understand the effect each and every change would/could produce. When developing the application specific software for a control system it is often done by teams of engineers working on different systems and therefore require the subsequent transfer of software between systems. This software transfer MUST be managed to avoid disasters.

DeltaV Configuration Management between Multiple Systems Version: 1.0

File Name: INT-DVMDS-001.docx For Information Only of 14

1.3 The Problem(s)

This section describes some of the problems associated with the management of configuration on multiple development platforms. It is essential to keep track of the master item of any individual software component. This ensures that the verified (i.e. tested / validated / proven) status is not compromised by unapproved alteration (this might include the item being accidentally or unintentionally changed or overwritten). Where a single development environment exists, (with DeltaV, this is where only a single ProfessionalPlus exists, i.e. no workstations), this problem does not arise as each configuration component is inherently unique within the DeltaV database / Graphics-iFix folder or Charts folder. However, to support large multi-personnel development teams within a single location, or globally, it is typically necessary to utilise multiple development platforms. Each platform has copies of common system components, and this gives rise to the potential for alteration of those common items on each of the platforms. (Refer to Figure 1-1 below) In particular, as workstations are added, the problem of master graphic control is introduced, as multiple copies of graphical components will now exist on multiple machines and have the potential to be individually altered. Refer to Section 1.7 DeltaV Operator Graphic Maintenance for details on how to avoid the potential pitfalls. With the increasing prevalence of virtual computing environments, there is a tendency to devolve development systems to individual personnel. Consequently, the potential to compromise the integrity of common software components greatly increases. In a phased delivery project, where the end-user (client) target system receives interim releases of system components over a phased period of time, this system must also be considered part of the development environment. It is critical not to compromise components on this system, as in many cases those components will already be involved in controlling the client live process equipment and management processes.

1.4 Considerations & Items for Discussion

From the problems highlighted above, it is clear that without a manual management strategy there is significant risk of compromising system components. Therefore a Configuration Management Plan (CMP) is necessary, even for the simplest of development environments (the single ProPlus), and this must be maintained and adjusted as necessary through the project life cycle. It should be developed and approved before component development begins, and all project personnel involved with component delivery must be aware of the document content and their role within the development cycle. The CMP should include figures giving physical and logic relationships of development systems: these should attempt to show time relationships of component transfer between the individual development systems, refer to Figure 1-1 as an example of a typical development environment arrangement. It is always worth assuming that delivery of software to the clients’ final target/production system will be performed in several managed phases. (E.g. Phase 1 – Base System components, Control Modules and Graphics, Phase 2 – Equipment Modules and Phase 3 Batch software components) Even if the initial project plan is for a single software delivery, a phased delivery approach should be defined within the configuration management strategy, as project timelines invariably alter, imposing a phased software release to the client target

DeltaV Configuration Management between Multiple Systems Version: 1.0

File Name: INT-DVMDS-001.docx For Information Only of 14

system upon the project team. Even if phased deliveries do not occur within the primary project development period, follow-on modifications performed back at base away from the client site should be considered in the same way as a second phased software release. The concept of a component “master” should be introduced, and the location of that master component should be tracked, along with its state of development. The types of system component to be developed and their inter relationships should be understood. For each component type the method of identification and version tracking control should be determined (note: it may not be possible to automatically track versions of all components, in which case manual methods should be used). A component inventory and status tracking system should be employed which should grow as controlled system components are added to the system. As a minimum for each component this should identify fixed stages of development, examples of this are “Implemented”, “code reviewed”, “internally tested”, “client tested”, “site tested” and “in service”. Note; Do not overlook inclusion of standard out of the box DeltaV components into the inventory, should it be necessary to alter these through the system lifecycle. The concept of component master and location should be introduced. During development the component master will likely exist on a development satellite system and this will migrate to test and development master systems as the status of the component progresses through “code review”, “internal test”, “client test” to the Master client system for “site test” and “in service” states. The simplest form of tracking system might well be an Excel spreadsheet. Although a system that allows simultaneous multi-user access and alteration of the tracking system is preferable, relational databases such as MS Access or MySQL might be considered. Remember that if the tracking system exists, the relevant engineers must know it exists and be trained in its efficient use. This should be a subject of CMP guidance. All personnel involved in developing the system components must have an appreciation of the particular system component they are developing, and also the inter-relationships with other computer system components. This is fundamental to the use of the CMP; it is pointless developing a CMP if people are not aware of it. This should form part of the project training/familiarisation process for that person (“go and read the CMP, come back with questions”).

DeltaV Configuration Management between Multiple Systems Version: 1.0 File Name: INT-DVMDS-001.docx For Information Only of 14

Client Master Live System

Client ProPlus Workstations 1 …………. x

Front Office Master Development/Test System

ProPlus Workstations 1 …………. x

Back Office 1 Master Development/Test System


Front Office Satellite

Development/Test System 1

ProPlus



ProPlus



ProPlus

Back Office 2 Master Development/Test System


Back Office 1 Satellite


ProPlus



ProPlus



ProPlus



ProPlus



ProPlus



ProPlus

Transfer of Components Between

Satellite and Master at a single

Geographical Location

Client Site System

Automation Vendor

Front Office

Automation Vendor Back

Office 1

Automation Vendor Back

Office 2

Transfer of Components Between

Geographical Locations

Component Feedback For

Further Development

Figure 1-1


Even when a CMP is well-devised and is well-practiced by all project team members, there remains a role(s) within a project with multiple development systems to police the practices of team members. On small to medium projects this would be a role for an engineer highly experienced in the particular computer system, its components and their inter-dependencies. This engineer should also act as a “gatekeeper” when system components are transferred from one development system to another to ensure only the correct components are transferred and no existing components are compromised. The “gatekeeper” may be known as the “system administrator” but they should have specific knowledge of the system being developed, not simply generic IT skills, a key requirement of this role which should not be overlooked. In Figure 1-1 there should be an incoming gatekeeper to each of the Master systems, i.e. four in this example. The same person could perform this role, but geographical constraints could dictate otherwise. The role could be performed remotely, but experience has shown that regular face-to-face contact is needed to perform the policing part of this role. The methods employed to prevent compromise of components by the gatekeepers can significantly determine the amount of effort taken during each transfer. Lack of component version control on each satellite/master development system can increase the effort for the incoming gatekeeper role. It must be recognised that the gatekeeper role imposes what appears at first to be an unproductive cost on the project. However, experience has shown the cost to a project that does not recognise this role can be considerably more in terms of rework, lost validation credit, technical credibility and reputation. DeltaV in particular offers an optional Version Control and Audit Trail (VCAT) system which should be considered an absolute must where a project plans for phased deliveries. This system allows automation of the many mundane activities associated with configuration management such as removing the need to perform component backups when overwriting (it automatically retains a snapshot) and component versioning (removing the need for manual tracking within that system). During the main project development phase VCAT is typically considered too burdensome an overhead for the configuration engineer (although Intuitive does not share this viewpoint). As the configuration master moves to the client site system, the vast majority of configuration changes should have been performed. There is no better solution to DeltaV component version tracking available. Intuitive strongly recommends the purchase and use of VCAT for the end user DeltaV database. Note: VCAT does not provide a solution for tracking component version between multiple development databases as the VCAT version number for the same component in each system is unique to that system, i.e. a component at version 6 on a back office development system will gain a version number of 1 when first imported to the front office system.

1.5 DeltaV-Specific Configuration Management Challenges

1.5.1 Introduction

Key to configuration management for DeltaV is a thorough understanding of the dependencies and interdependencies of the individual configuration components of DeltaV. Put another way, knowing the impact that altering any component of the DeltaV configuration will have on other components is key to avoiding situations where proven components are altered, compromising their validated status. For example altering a single Named Set (a Named Set is a common global item in a DeltaV configuration) could compromise thousands of validated (tested and potentially ’in service’) configuration components. This would necessitate a controller download with the consequence of operational disruption for the client.


1.5.2 DeltaV architecture

DeltaV configuration can be considered a pyramid of configuration components, where foundation components such as Named Set, Function Blocks, System Security, and Alarm Types form the base layer of the pyramid. Onto this composite blocks are built, on top of which control modules and control module classes are built, on top of which equipment module and equipment module instances are built, on top of which control module and equipment module instances are built, on top of which phases are built, on top of which Operation, Unit Procedures and Procedures are built. (Refer to Figure 1-2). Any alteration of a foundation layer (lower block in the pyramid) has the potential to impact on many higher layers of the pyramid.

Named Sets Security Function Blocks Alarm TypesEngineering UnitsI/O Configuration

DSTs

Composite

BlocksControl Modules Unit Modules

Control Module

Classes

Equipment

Module Classes

Equipment

Module Classes

Control Module

Instances

Equipment

Module Instances

Equipment

Module Instances

Phase Classes

Phases Instances

Operations

Unit Procedures

Procedures

Equipment

Modules

Unit Module

Classes

Unit Module

Instances

Physical Nodes

Controllers/StationAlarm Areas

Figure 1-2

1.5.3 Import and Export

DeltaV allows for individual components to be transferred between configuration databases using the standard “export” and “import” utilities and this is where problems can begin. When a standard export is made from DeltaV Explorer, an “fhx” file is created. The structure of an fhx file (which is a simple human-readable text file) typically provides the individual component(s) and the components on which it/those is/are dependent. This approach allows the component(s) to be successfully recreated in the recipient database. The export fhx file can be considered as containing the upturned pyramid for the individual component that is exported (the individual component is included at the end of the file and all of the components on which it depends are included towards to the start of the file). For example, the export of a Control Module Instance will include the specific Control Module Instance at the bottom of the file, the control module class on which it is based will be included above that, any composite blocks and function blocks will be included above that and any function block required by the composite blocks will be included above those.


Start of an FHX file.

Schema

Details of the DeltaV system and version. Always

present.

Locale

Details of language. Always present.

Plant Areas

Control strategy alarm areas. Included when

components of a control strategy are exported. (i.e.

Unit, Equipment or Control Modules)

Function Block Templates

Basic Function Blocks AI, AO, CND, ACT, CALC, OR

etc. Included if modules or composites used these.

Function Block Definitions

Linked Composite blocks, examples from Emerson

PCSD Library are C_C_IL52, C_C_ML52 and

C_AI_RATE52. Included if modules or phases use

these.

Embedded Composite blocks

example __523712D6_02C11D89__. Included when

modules or phases use embedded composites.

Module Classes

Control and Equipment Module Classes, examples

from the Emerson PCSD Library are _CSD_52, _DI_52

and _AI_FF_52

Batch Equipment Unit Modules

Unit Modules, non class based. Included if a Unit

Module or a module sub-ordinate to a Unit Module is

exported.

Module Instances

Control and Equipment module instances based on

module classes

Non Class Based Modules

Control and Equipment modules not based on a class.

End of an FHX file.

Figure 1-3: FHX File Structure

There are exceptions to this typical arrangement, one of which is that Setup data elements (such as Named Sets and Alarm Types), as shown in the bottom layer of Figure 1-2, are generally not included. Therefore if a component is to be imported to the recipient database and that Setup component does not exist, the import will usually be rejected by the recipient database import. The Setup component must first be individually transferred or created to/on the recipient database. Another exception is where a module instance exists under a unit module within the DeltaV control strategy hierarchy. When the module is exported, the unit module is also exported and if that is a class-based unit module, the unit module class and all of the components on which that unit class is dependent is also included in the fhx file. This includes phases, and all of their component dependencies. So what you might initially expect to be a very small export file can actually be very large.


1.6 DeltaV Import Basics

1.6.1 Preparation

As a disaster recovery measure, always perform a complete fhx backup of the whole database, or at least individual components you intend to overwrite, before performing any database imports. Be aware of the multi-user nature of the DeltaV database and recognise that other users may be simultaneously altering components while you are performing the import activities. Therefore even in the event of an import failure, the full fhx backup you performed may not fully reflect the latest status of the database, should you need to recover from the backup fhx file. In this case you should liaise with those other engineers to ensure you do not overwrite their work. Ideally you should have sole access to the database while performing import activities, although this is not always practical. Important Note: Taking a backup is only part of a backup/disaster recovery regime. You should also regularly check that the backups being taken are actually usable. It is not unknown for a backup to be incomplete of all necessary components or the backup files to be corrupted.

1.6.2 Import Logs

When a DeltaV standard import is performed, a log file is created in the DeltaV\DVData working folder on the Professional workstation form which the import was performed. The log file is called “ImportExportProgress.log” and it provides a report of the items that were Skipped/Updated/Added and any errors or warnings that occurred during the import. As a good practice measure, each of these log files should be saved and reviewed to confirm the expected actions were actually performed, i.e. only those items that should have been added have been added, updated or skipped, and that errors and warnings have been assessed, addressed or at least recognised and reported. Best practice is to store the Log file in the same location as the import fhx file and rename it by prefixing with the same name as the import fhx file. For example if an import fhx file is named “Subset of Area_A.fhx”, then store the ImportExportProgress.log file as “Subset of Area_A ImportExportProgress.log”. Note that if two imports are performed simultaneously on the same Professional workstation, one of the ImportExportProgress.log files will be overwritten, therefore it is important to ensure import activities on the same Professional machine are coordinated to prevent this occurring. This is particularly an issue on Remote Access machines used as Professional workstations.

1.6.3 Importing New Components into the recipient database

When using the standard import utility on the recipient DeltaV database, if a component contained in the import fhx file does not exist in the recipient database it will be added automatically providing any components on which it is dependent already exist in the recipient database.

1.6.4 Importing Setup Items (Named Sets, Alarm Types)

When importing certain Setup component types, such as Named Sets and Alarm Types, the import utility does not prompt the engineer to confirm overwrite if the component already exists in the recipient database (unless it is read-only). Therefore you should always try and avoid importing the whole Setup, Named Set or Alarm type categories. You should only import individual components or a subset of components you definitely want to overwrite.


1.6.5 Importing an Existing Item into the recipient database (Overwriting)

Each item included in an export “fhx” file contains a time stamp and username related to the donor database. When the import utility identifies a component for import that already exists in the recipient database it compares the timestamp and username associated with that item in both. If timestamp and username match the import of the item is automatically skipped as it believes both components are identical and therefore does not need to be imported. If the item is determined to be different because the timestamp or username are different, the import utility will offer a prompt that must be answered by the engineer. The options provided are “No”, which skips just this component; “No to All” skips all components in the remainder of the fhx file, “Yes” which overwrites just this component, “Yes to All” which overwrites this component and all remaining components in the fhx file or “Cancel” to cancel the entire import from that stage onwards (Refer to figure 1-4 below).

Figure 1-4

Note that the last option “Yes to All” must be considered a very dangerous option and should only be selected when importing into a completely blank database, otherwise avoid it. The selection of “Yes” should also be seriously considered before selecting, as selecting yes for the wrong element could trigger the need for a download of most control modules in the system in the instance where “Yes” to update the “CND” function block is accidentally selected. Note: When importing and overwriting a select group of components from a single fhx file it is good practice to move your hand away from the mouse button (or enter key) after each “Yes” selection and only move your finger back to the mouse when you are sure you want to select “Yes” again.

1.6.6 Importing an Embedded Composite Block

When importing a component that contains an embedded composite block, the composite block will have been allocated an internally generated name by the system of a format similar to “__52555335_002C75E5__” If this item already exists in the recipient system it will be exactly the same item, as the number is essentially a unique identifier for that components contents i.e. a checksum. You should select “Yes” to overwrite. If presented with the “The database already contains….” prompt for a component with a name similar to this it’s very hard to determine what the item relates to (without delving into the fhx file to determine). It is always safe to answer “Yes”. .


1.7 DeltaV Operator Graphic Maintenance

The DeltaV system maintains the graphical components used by the DeltaV Operate user interface application in an entirely different way to that of system control logic as described in Section 1.5. In a typical DeltaV arrangement (there are other methods of deployment), the master set of graphical components of the system are stored in the “Graphics-iFix” folder of the DeltaV\DVData working folder of the ProfessionalPlus engineering station (Pro+). For rapid access to graphic files the individual operator workstations do not directly access the graphical components on the Pro+ machine, they access a local copy stored in the working “Graphics-iFix” folder of that workstation. This is where configuration management problems can start to occur.

1.7.1 The Auto-Update service

DeltaV provides the Auto-Update service which attempts to keep the local copies of graphical components on operator workstations synchronised with the Pro+ master versions, but this whole process relies on knowledge of the Auto-Update operation and on manual actions to ensure it works for you rather than against you. A very good Emerson Knowledge Based Article (KBA AP-0500-0084) provides details of the Auto-Update replication service. Auto-Update service was previously known as YellowPages and within the DeltaV community these names are used interchangeably. DeltaV still uses folders named YellowPages for the Auto-Update service.

Figure 1-5: Example A – ProfessionalPLUS distribution to Workstation(s)


Figure 1-6: Example B – Upload a modified graphic from a Professional Station & distribution to other Workstation(s)

In simple terms the Auto-Update service works in the background of the Pro+ workstation (as the name suggests) and takes a copy of most graphical elements and stores them in the YellowPages distribution folders of the Pro+ machine. A download of any type to the Pro+ node initiates the copy of new and updated files from the Pro+ Graphic-iFix working folders to the YellowPages distribution folder of the Pro+ machine. (The graphical elements are stored in a compressed format in these YellowPages distribution folders, to minimise network traffic during distribution) The next step is to synchronise workstations with updated or new graphical components. That is initiated by performing a download to the workstation or workstation you wish to synchronise (a changed setup data download is sufficient to trigger the synchronisation process) The Auto-Update service of the Pro+ then schedules distribution of the compressed graphical components from the YellowPages folder of the Pro+ machine to the workstation node(s) downloaded, provided they are also set for Auto-Update through the Auto-Update configuration client. In worst cases this scheduled distribution process can take a day or more to fully distribute all graphic components to all workstation in the system, depending on the number of workstation nodes and quantity of files. This worst case is typically only during initial graphic distribution to a clean, newly installed workstation. Rest assured, if the process starts to work it will complete the process. Patience is needed, do not be tempted to copy the files directly using Windows explorer, as this will compromise the reliable operation of the Auto-Update system


from that point onwards. If you want to check Auto-Update is working away in the background, go to DeltaV Diagnostic and select the Auto-Update Diagnostics utility from the Tools menu. This will show distribution status and progress. Note the information provided relates to the workstation on which you run the Auto-Update Diagnostics utility. There is a complementary Auto-Update service running on workstations which receives these graphical elements and stores them in the workstations’ YellowPages distribution folders. The Auto-Update service running on the workstation then transfers the updated/new graphical component from its YellowPages folder to the working Graphic-iFix folder of that workstation. This process will only occur if the particular graphical element is not currently in use (locked) by the DeltaV Operate application running on the workstation. Note this particularly affects the User.fxg, Siglobal.fxg and other globals.fxg files which are locked for pretty much the duration of the DeltaV Operate operation, therefore to allow an update of these files DeltaV Operate application must be closed down temporarily to give the Auto-Update service chance to perform the overwrite operation. Other graphic components that are continually open such as toolbars and alarm banners, or an operator’s favourite graphic, will also be locked and will not be updated until DeltaV Operate is closed down or the favourite graphic is no longer open on the workstation.

1.7.2 Auto-Update implications

The Auto-Update service gives rise to a number of configuration management problems, which centre around the fact that DeltaV Operate allows graphical components to be modified locally on the Professional workstations. The Auto-Update service tracks timestamp details of graphical component copies and uses this information to determine which files to overwrite in the working folder and which files to leave alone. Auto-Update service will not overwrite a local copy of a graphical component in the working folder if its timestamp differs from the timestamp of the file automatically copied to the working folder by YellowPages last time the file was distributed. This is because it is an indicator that the file has been altered/edited or added directly with a different version not associated with a YellowPages distribution, and it doesn’t want to lose valid alterations. It is the responsibility of the engineer or technician (user) performing the graphic component modification to manually upload their change to the Pro+ machine after alteration. They should use the Workstation/Upload feature of DeltaV Explorer, not perform a direct copy using Windows Explorer. Due to lack of understanding of the Auto-Update system, we have seen many clients lose confidence in the Auto-Update system and simply disable it and perform manual copying of files from the Pro+ to workstations and vice-versa. The typical problems that can arise due to reliance on a manual process are:

1. The same graphical element is updated simultaneously on two or more Pro+/Pro workstations. Each user uploads their modifications and one of the users loses their modifications. The other users’ changes/proven/validated modification is lost and nobody is immediately aware of the problem.

2. Uploads are not performed by the user and only that workstation is running a different graphical component to other workstations rightly or wrongly (usually wrongly). Subsequent component updates are not distributed to this workstation.

The configuration management and policing of system activities should address this scenario, provide a solution and users should be educated in the process.


1.8 Conclusions

Managing the transfer of software components between multiple DeltaV systems is a complex task that must be managed effectively to avoid potentially disasters. It requires a methodical and meticulous “gatekeeper” that fully understands the technical aspects, transfer processes and is totally focused on retaining the validation integrity of each system. To assist with managing the transfer of software components between DeltaV systems it is strongly recommend that the DeltaV Version Control and Audit Trail (VCAT) Utility is utilised. Particular attention should be applied to the development and transfer of Operator graphics as incorrect changes will adversely affect the Auto-Update utility. As a result of these aforementioned problems when managing software components between multiple systems, To aid these tasks, Intuitive have developed the following tools: DeltaV FHX Extract and Compare: Compares and visualise the differences between the components contained in two DeltaV fhx export files. This rapidly allows confident and educated decisions to be made as to which component to import when presented with a new release of DeltaV components from a donor development system. DeltaV FHX ImportExportProgressLog Capture: Automates the process of capturing and archiving the ImportExportProgress.log file at the click of a button. It makes an otherwise tedious manual activity easy and therefore there is no reason not to do it. iFix to XML Graphic Convertor: The Intuitive IFIX XML Documenter is a productivity tool that allows an engineer to document the configuration and properties of iFIX documents such as Pictures, Dynamo Sets and Global files in an XML format. The tool can assist in configuration management by providing more than a simple "the Graphic file and date check", you can easily find the real differences. For troubleshooting where someone says "the graphic worked last week, why doesn't it now?" DeltaV Online Change Report Tool: During intensive online commissioning stages and prolonged operational periods is it extremely hard to track online tuning changes made by commissioning engineers and automation support technicians. These tuning changes need to be retained in the offline configuration database to prevent loss in the event of total controller download or controller failure. It is possible to upload online changes with DeltaV, but Intuitive advise against this as it is too easy to upload changes that are not intended. The standard interface provided by DeltaV out of the box for reporting and reviewing these online changes doesn't allow easy export to an open format to allow thorough analysis using simple applications such as MS Excel. Step in the Intuitive DeltaV Online Change Report Tool. This allows online changes from all, one or a select group of DeltaV nodes to be exported to CSV or XML format files to facilitate import to many data analysis tools. Changes can then be analysed by parameter name, value, time of change, or user drastically simplifying the decision whether a change is a true tuning change to be retained or is operational noise to be ignored.

Head Office +44 (0)161 928 8239

email [email protected]

web www.intuitive.uk.com

Post Caspian House

Caspian Road

Altrincham

Cheshire

WA14 5HH

United Kingdom

Intuitive is an ISO9001:2008 accredited company specialising in the design, configuration, testing, commissioning and support of ProVox & DeltaV Basic Process Control (BPCS) and Safety Instrumented Systems (SIS) for industrial batch and continuous process application in a variety of industry sectors such as pharmaceuticals, fine chemical, plastics, water and nuclear

mailto:[email protected]

http://www.intuitive.uk.com/

Guidance Notes for DeltaV Configuration … · DeltaV Configuration Management between Multiple...

Documents

Transcript of Guidance Notes for DeltaV Configuration … · DeltaV Configuration Management between Multiple...