html

SCADA Project Development Workflow

Before starting development work on a typical SCADA project, it is necessary to determine which devices the system will collect data from, which data will be monitored, which users will access the system, which alarms will be generated, and how the data will be archived.

After these preparations, the project configuration is performed and the SCADA screens are created. In the final stage, user permissions, alarm mechanisms, data archives, and operational checks are completed, making the project ready for use.

Important: The sequence below represents a typical SCADA project development workflow. Depending on the size of the project, the devices used, and the requirements, the order of some steps may change, or some steps may not be required for a particular project.

1. EOS Project Database Settings (OPTIONAL)

To create the basic data structure of the SCADA project, the necessary settings related to the EOS Project Database should first be configured.

This step provides the basic data environment on which the other project configuration components will be built.

The User Can Use the Default Settings.

2. General Settings (OPTIONAL)

The general operating parameters and system behavior to be used in the project should be defined.

These settings include the basic configurations that determine the general operating characteristics of the SCADA application and the working environment presented to the user.

The User Can Use the Default Settings.

3. Project Settings (OPTIONAL)

The project name, description, security settings, and other project-level information to be used within the project should be defined.

These settings form the basic configuration information that defines the project as a whole, independently of its other components.

The User Can Use the Default Settings. However, it is recommended to configure separate settings for each project.

4. Entering Device Information (REQUIRED)

Field devices, controllers, RTUs, or other data sources with which the SCADA system will communicate must be defined.

The communication method, address information, and other parameters related to the communication protocol used by the devices are configured at this stage.

Correct device definitions are one of the fundamental requirements for the SCADA system to access field data reliably.

5. Entering Data Lists (REQUIRED)

The process data to be read from field devices or used by the SCADA system must be defined.

For each data item, the relevant address, data type, description, engineering unit, scaling, and other required parameters can be specified.

This stage is critical for establishing the data model between field communication and the SCADA application.

6. Creating Virtual Data (OPTIONAL)

If the project requires data that is not directly read from a physical field device but is needed for calculations, logical operations, status evaluation, or screen design, virtual data can be created.

This step depends on the project requirements and is not required in every SCADA project.

Optional if the use of derived data is not required.

7. Preparing Visual Objects (OPTIONAL)

If custom graphical objects or user controls are required for use on SCADA screens, these objects should be prepared before starting screen design.

Prepared visual objects enable process equipment and system statuses to be presented to the user in a clearer and more understandable manner.

In projects where custom visual objects are not required, this stage can be completed using the available predefined objects directly.

8. Designing SCADA Screens (REQUIRED or OPTIONAL)

Once the project's basic data structure and the visual objects to be used have been prepared, SCADA screen design can begin.

Process equipment, measurement values, status information, control elements, alarm indicators, and other user interface components are created on the screens.

The primary objective of screen design is to enable the operator to quickly and accurately perceive the process status and safely intervene when necessary.

Design Recommendation: Unnecessary visual clutter should be avoided on SCADA screens. Critical information should be easy to identify, and screens should be designed consistently and in a manner compatible with the operator's usage habits.

If only Event Recorder software is used, SCADA screen design is not required.

9. Creating the Personnel List (REQUIRED)

Personnel records should be created for operators, engineers, maintenance personnel, and other users who will use the SCADA system.

User access to the system and the operations they are permitted to perform can be managed based on this information.

10. Configuring Personnel Permissions (REQUIRED)

The operations that each person defined in the system is permitted to perform must be determined.

User authorization enables an access level appropriate to each user's duties and responsibilities to be established.

Appropriate authorization is particularly important for operational security when performing operations such as control, changing settings, project management, and critical system functions.

11. Entering Alarm Types (REQUIRED or OPTIONAL)

The alarm types to be used in the SCADA system must be defined.

Alarm types are used to classify different conditions occurring in the system and present them to the operator in a meaningful manner.

REQUIRED if alarm monitoring will be performed; otherwise OPTIONAL.

12. Entering Alarm Groups (REQUIRED or OPTIONAL)

The necessary alarm groups should be created so that alarms can be organized by plant, unit, system, or function.

Appropriate alarm grouping enables operators to more easily monitor important events among a large number of alarms, particularly in large SCADA projects.

REQUIRED if alarm monitoring will be performed; otherwise OPTIONAL.

13. Entering System Alarm Definitions (NOT IN USE)

System alarm definitions should be created to report the operating status of the SCADA system or system-related problems.

Communication problems, data quality issues, operating conditions of system components, and similar conditions can be evaluated within this scope.

System Alarms have not yet been integrated.

14. Creating Alarm Lists (REQUIRED or OPTIONAL)

Alarm lists to be monitored in the project should be created using the defined alarm types, alarm groups, and system alarm information.

Alarm lists should be organized so that operators can identify abnormal conditions in the process in a timely manner and perform the necessary intervention.

REQUIRED if alarm monitoring will be performed; otherwise OPTIONAL.

15. Main Archive Database Settings (OPTIONAL)

The necessary connection and configuration settings for the main archive database where historical process data will be stored should be configured.

Proper planning of the data archiving structure is important so that historical process information can later be used for trending, reporting, and analysis.

The User Can Use the Default Settings.

16. Defining Additional Local Data Archives (OPTIONAL)

If additional local data archives are to be used according to the project requirements, the database information for these archives must be defined.

This structure can be used particularly in projects where different plant sections, local systems, or special data groups need to be stored in separate archives.

17. Completing Data Archive Selection Lists (REQUIRED or OPTIONAL)

The relevant selection lists should be created to determine which data will be stored in the main data archive and, where applicable, in additional local data archives.

At this stage, the process data to be stored historically is determined, preventing unnecessary data storage and ensuring that the archive structure meets the project requirements.

REQUIRED if data archiving will be performed; otherwise OPTIONAL.

18. Completing the SCADA Design

Once the project database, device, data, screen, user, permission, alarm, and archive configurations have been completed, an overall review of the SCADA design should be performed.

At this stage, it should be verified that the screens operate correctly, data is read from the correct sources, alarm conditions are generated as expected, user permissions are correctly applied, and historical data is properly archived.

Once the necessary checks have been completed, the project can be prepared for the operating environment and the commissioning process.

19. Testing and Commissioning

After the SCADA design has been completed, it is recommended that the system be tested before transitioning to actual operating conditions.

Communication connections, data values, data quality, screens, control operations, alarm generation, user permissions, and data archiving functions should be checked.

After identified errors have been corrected and the system has been verified to operate as expected, the SCADA project can be commissioned.

Recommendation: During testing and commissioning, checking only the appearance of the screens is not sufficient. It must also be verified that the SCADA system communicates with field devices, processes real data correctly, and presents accurate information to the operator.

Typical SCADA Project Development Workflow

The development of a typical SCADA project using the EOS SCADA Editor can generally be carried out according to the following workflow:

  1. EOS Project Database settings (Optional)
  2. General settings configuration (Optional)
  3. Project settings entry (Optional)
  4. Device information entry (Required)
  5. Data lists creation (Required)
  6. If required, virtual data creation (Optional)
  7. If required, visual objects preparation (Optional)
  8. SCADA screen designs creation (Required or Optional)
  9. Personnel list creation (Required)
  10. Personnel permissions definition (Required)
  11. Alarm types definition (Required or Optional)
  12. Alarm groups creation (Required or Optional)
  13. System alarm definitions creation (Not in Use)
  14. Alarm lists creation (Required or Optional)
  15. Main archive database configuration (Optional)
  16. If required, additional local data archives definition (Optional)
  17. Data archive selection lists completion (Required or Optional)
  18. SCADA design completion
  19. Testing and commissioning activities

Basic Approach to SCADA Design

The primary objective in developing a SCADA project is not merely to create a functioning user interface, but to establish a reliable operating environment that addresses field data, communication, operator interaction, alarm management, and historical data archiving as an integrated whole.

Therefore, during the project development process, it is appropriate to first establish the data and device structure, followed by the user interface, and then configure the user, alarm, and archive functions.

The following sections of the EOS SCADA Editor User Guide have also been prepared according to this approach and explain each of the above stages separately.

Conclusion: A well-planned SCADA project should have a correct data model, reliable communication, clear screens, controlled user access, proper alarm management, and reliable historical data archiving.

← Back to Previous Content