Ease of Use in Engineering
An engineering support system for developing control systems needs to have simple and intuitive engineering based on standardized function blocks and cooperation with process planning and plant engineering tools (computer-aided design/computer-aided engineering; CAD/CAE). Also needed are ease of mapping plant equipment or process structure into the software structure, solving of complex automat...
An engineering support system for developing control systems needs to have simple and intuitive engineering based on standardized function blocks and cooperation with process planning and plant engineering tools (computer-aided design/computer-aided engineering; CAD/CAE). Also needed are ease of mapping plant equipment or process structure into the software structure, solving of complex automation tasks, and tools for easy development of custom libraries.
These features sometimes supplement one another, such as the demand for intuitive engineering coupled with the mapping of the plant equipment into the software structure. Sometimes, however, they contradict one another, such as when the drive to use standards conflicts with the need to solve complex automation tasks.
Core functionality needed to support complex-system development includes:
Ability for multiple engineers to work concurrently on the same project;
Direct mapping of the plant structure into the application software;
Efficient and intuitive configuration of continuous processes;
Efficient and intuitive configuration of sequential processes;
Data consistency through one entry point;
Overview of all engineering aspects; and
Transparency between the engineering of the control strategy and the human machine interface (HMI) software.
Having an appropriate number of project engineers organized into a team structure is an important requirement for any complex project, but each engineer needs to work with the same database.
As a result of globalization and outsourcing to reduce cost, it is often necessary to distribute portions of the engineering effort throughout the world, yet the engineering system needs to support every team member. Even with the Internet, not every participant can have instant access to the system at all times. Tools should combine intermediate results and support data exchange between team members. An engineer working on HMI software must be able to access the current intermediate version of the controller automation software.
Software tools should help support concurrent, collaborate file modification.
Multi-project functionality can create a wrapper around several subordinate projects that can, in fact, be saved locally on different PCs. If the PCs reside on a common network, the engineering workflow process becomes relatively straightforward. Each employee works locally and can access work posted by others online. Users can integrate intermediate results from others not working online into the central project at any time. In the opposite direction, team members should be able to share intermediate results easily via e-mail or other file-transfers.
For example, an engineering station contains the overall project and subordinate projects. These files may contain configurations for controllers and an HMI server. The project for the other controller is saved on another engineering workstation, and projects for another controller and HMI on a different server. Ideally, for maximum flexibility the engineering team can test subordinate projects in a standalone mode by downloading files onto the appropriate target system, or by generating the complete project and downloading it onto target systems.
Process control systems, such as Siemens Simatic PCS 7, include tools to ease programming and configuration, such as this import/export assistant (IEA) table.
In addition, an administrator should be able to generate a project backup, saving work in progress. All configuration objects (such as hardware configurations, control strategy, process graphics, alarm messages, and archive descriptions) are grouped and saved. Selecting individual objects (such as process graphics) belonging to the project is unnecessary.
Plant, software structure
Users typically want to ensure that the software configuration structure matches the plant/process layout or equipment structure to make troubleshooting and maintenance as easy as possible. Plants are usually divided into process cells, then into units or areas that subdivide into pieces of equipment made of individual control strategy elements (control modules).
Such a scheme typically generates a hierarchical structure of no more than five levels. Engineers need a graphical language to configure these elements using function blocks, continuous function charts (CFCs), sequential function controls (SFCs), ladder logic, or structured text.
Users should configure control strategies as the basis for generating process graphics and creating HMI navigation. Users can link process graphics to the control strategy, allowing the system to create HMI graphics and associated hierarchy from controller configuration. Other users may seek to lay out the structure of the controller and HMI independently. The system should provide tools to support both applications, and automatically propagate typical configuration changes within the control strategy, such as changing the instance name of a function block, to HMI elements. This capability minimizes configuration errors.
When copying sections of the process facility to create, for example, parallel process flows, the system should ensure that configurations for all subordinate levels, including charts and process graphics, are be copied as well and automatically updated to reflect their new instance. In addition to providing a view into the engineering system that reflects the plant’s process structure, there should also be views dedicated to component and network structures, where it should be possible to handle and configure these separately.
Viewing process objects can facilitate complete project administration and provide one point of configuration for control module aspects, such as control parameters, alarm priorities, messages, historical data, and I/O assignment. Simple selection boxes should allow the engineer to define HMI tag-naming structure easily and select if the process graphic HMI structure derives from the controller configuration.
In addition to the process object view and the plant view, an engineering system should provide a component view that presents configuration from a hardware-centric point of view, optimized for a technician or maintenance person. Component view should allow users to manage all controller hardware and PCs with the applications. When component and the process-object views are independent, objects in the process object view can be freely assigned to individual controllers and HMI stations. That allows control logic charts to be assigned to a specific controller and pictures to the operator stations onto which they are to be downloaded and executed.
By using generic names to clarify the hierarchical structure in process object view, all subordinate projects in the hierarchy can be identical. Such a structure is important for an engineer working on a small piece of a large project since it presents enormous advantages when merging subordinate projects.
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.