Internal structure and data flow

The project runtime runs on a variety of platforms and consists of the following modules or threads (program elements that can execute independently of other program elements):

Background task

A supervisory task that executes other internal tasks (worksheets). For example, the Background task executes scripts configured in the Script, Math, and Scheduler worksheets, and manages parameters configured in the Alarm, Recipe, Report, and Trend worksheets.

Watch

A debugging tool that…

• Executes functions and/or expressions for testing purposes

• Reads data (such as tag values) from the tags database

• Writes data (such as tag values) to the Tags database

  LogWin

  A debugging tool that traces messages generated from other modules/tasks.

  Mobile Access Runtime

  Manages communication between your project runtime server and the web server that hosts the Mobile Access web interface.

  Driver Runtime

  Manages the read/write commands configured in the Driver worksheets.

  OPC client

  Manages OPC communication with an OPC Server (local or remote), according to parameters configured in the OPC Client worksheets.

  OPC server

  Manages OPC communication with an OPC Client (local or remote).

  TCP/IP client

  A "thick client" that manages TCP/IP communication with the TCP/IP Server module in another project, according to parameters configured in the TCP/IP Client worksheets.

  TCP/IP server

  Manages TCP/IP communication messages with both thick clients (that is, the TCP/IP Client module in other projects) and thin clients (that is, the Viewer module).

  Viewer

  Executes all scripts (On Open, On While, On Close, Command, Hyperlink, and so forth) configured for project screens and updates the screen objects.

None of the preceding runtime modules exchange data directly with another module or task. Instead, runtime modules send data to and receive data from the tags database, which is the heart of the project.

The tags database manages the flow of data between modules. In addition, the tags database stores all tag values and the status of all properties associated with each tag (such as alarm conditioning, timestamp, quality, and so on).

Tags are variables (such as communication points in field equipment, calculation results, alarm points, and so on) that are used in screens and worksheets. For more information, see Tags and the Project Database.

Each runtime module contains a virtual table of the tags that are relevant for that module at the current time. The tags database uses this table to determine which information must be updated in each module. For example, the Viewer contains a virtual table that lists all tags configured for all of the open project screens. If a tag value changes, the tags database sends a message to the Viewer, and then the Viewer updates the value in all objects where the tag is configured.

For example, if a driver reads a new value from the PLC, the driver updates the tag associated with this value in the tags database. Then, if this new information must display on the project screen, the tags database sends the new tag value to the Viewer task, and the Viewer updates the screen.

Note that the driver does not send new tag values directly to the Viewer. In addition, there is no pooling between tasks — the tags database receives the updated information and immediately forwards it to all runtime tasks requiring that information.

Note: The Viewer module will update an object only when (at least) one of the object's tag values change.

If you configure an object animation (such as Text Data Link) with a function that does not require a tag (such as NoInputTime), then the Viewer will not update the object because there is are no tags associated with that object.

The software architecture significantly improves the internal data flow performance and makes it easy for you to add new internal tasks. Even though each task works independently, it can access information from any other task through the tags database.