Home

1. Introducing the PAL

The Practical Series Automation Library (PAL) is a library of software modules and templates that have been developed for the Siemens Simatic S7-1500 range of controllers (and to a lesser extent the S7-1200 range).

The latest version of the PAL software library is available to download here (as a TIA Portal archive):

https://practicalseries.com/2001-pal/31-git/81-00-archive.html

All the associated documentation is available to down load here:

https://practicalseries.com/2001-pal/21-project/01-00-docs.html

The PAL is configured and deployed using the Siemens Simatic TIA Portal programming environment.

The PAL software structure is designed such that it is applicable to virtually all industrial applications that can generally controlled by a programmable logic controller (PLC) or, to use Siemens terminology, a “Controller¹”.

In general terms, the PAL software being developed as part of this Project, is considered to be suitable for use in the following types of industries (this is not an exhaustive list):

Water and waste water treatment
Pharmaceutical and batch production
Brewing and fermentation
Chemical manufacturing
Oil and gas systems
Food and beverage production

At its most basic level, the PAL will be a library of software modules that control the fundamental aspects of an industrial plant; such modules would for example read the value of an instrument, operate a valve or drive, perform a calculation &c.

Such software modules are referred to as standard modules, these are fixed modules that perform a particular function and are identical across all software installations.

The PAL has many such modules; making up the bulk of the PAL.

The PAL also contains application specific modules; these contain software that is applicable to the plant being controlled.

For example, if a project were to control five valves, there would be an application module that called the standard valve device driver five times and each instance would link the standard module to the particular signals and internal storage locations associated with the valve in question.

The standard modules within the PAL will be fixed modules, the software within these modules will be written, tested and validated as part of this Project and at only that point will the modules be released for use. Once released, the modules must not be modified or changed in any unauthorised way, to do so would invalidate the software.

Note

¹ The Siemens Simatic S7-1500 and S7-1200 range of Controllers are, what would be generally understood to be, program logic controllers (PLCs); Controller is simply the common term used within Siemens literature for this type of device. For clarity, where a Siemens Controller is being referred to, the word Controller is capitalised (to indicate it is a Siemens Controller, rather than some non-specific controlling device).

The further modification of any of these standard modules (or indeed the addition of further standard modules) will only take place under the Project change control put in place by the Quality Plan or under the control of subsequent future projects.

Application modules are specific to each individual plant within which the PAL is deployed; they will be written for a particular project and are configured to match the requirements of that project.

Although individual in nature, the type of application modules required by a particular project will be part of a universal set of such modules, this set of modules determines the fundamental structure of the software, for the PAL, these are broadly:

System (internal) signal generation
Instrumentation
Safety and interlock systems
Calculations
Continuous control
Sequence control
Command execution logic
Device handling (control loops, valves, drives &c.)
Alarm handling
Communications

Each application module will also have to conform to the standards, formats and specifications laid out in the various requirements and design documentation associated with the PAL project.

As such, a comprehensive set of template Although the interfaces for display and control are defined as part of this Project, the supervisory systems themselves (SCADA, HMI &c.) will not be developed as part of this Project, the interfaces (and to some extent the expected appearance of the graphical symbols that would be used in such systems) will be developed in their entirety. application modules will be designed, developed, tested and issued as part of the Practical Series Automation Library Project.

These modules will serve as example modules to demonstrate how the PAL modules should be used, and the best practices for doing so.

There will also be a series of documentation modules that demonstrate how the modules should be documented, commented and named.

Certain modules within the PAL library, will have operator interfaces; typically, these are modules for reading instruments, managing equipment (drives, valves, loops) and controlling various aspects of the plant control (sequences for example). These interfaces require that the mechanisms for displaying the status of instruments and devices and for controlling those instruments and devices, be established as part of this design.

Although the interfaces for display and control are defined as part of this Project, the supervisory systems themselves (SCADA, HMI &c.) will not be developed as part of this Project, the interfaces (and to some extent the expected appearance of the graphical symbols that would be used in such systems) will be developed in their entirety.

⬆️ Top

1.1. The approach taken

The requirements for this Project specified in the User Requirements Specification URS, are to build a library of Siemens Simatic Controller software modules that will be applicable to virtually all industrial applications that can generally be controlled by such a Controller.

The design necessary to achieve these requirements was broken down into the following components:

Determine the overall structure of the software that is to be used as the basis for all industrial application deployments, this will form the basis of the required application modules
Determine the standard modules that are to form the library
The design of the end-user interface for certain specific modules that require such an interface
Establish a series of template and document modules that can provide example usage of all the standard and application module in context

A brief overview (a summary or abstract) of each of these points is given in the sections below: structure of the software.

⬆️ Top

1.1.1 The structure of the software

The software within a Controller is generally structured in a logical order; that order is determined by the sequence used by the Controller is to process the information available to it and to then act on that information.

For example, if it were the function of a Controller to close a valve if a tank reached a target level and open it if below that level, the logical order of events would be:

Read the tank level instrument
Evaluate the level (is it above the target level)
Act on that information to either open or close the valve

There is no hard and fast rule for how a Controller programme should be structured; it can be done many in different ways. That said, there are certain common approaches and some measures of good engineering practice that are generally applied to the structure of a programme and these will be adopted within the PAL.

The PAL will broadly adopt the following overall software structure:

classDiagram
System-Functions : ● Generates common global system signals and timing pulses
System-Functions : ● Reads Controller cycle and real time clock information
System-Functions : ● Reads and identifies any module and system faults
System-Functions-->Read-Instruments

Read-Instruments : ● Reads all analogue and digital instruments
Read-Instruments : ● Scale analog instrument in engineering units
Read-Instruments : ● Digital instruments signals are filtered and stored
Read-Instruments : ● Generate instrument alarms and warnings
Read-Instruments-->Interlocks-and-Protection

Interlocks-and-Protection : Interlocks are overriding conditions that prevent 
Interlocks-and-Protection : something from happening when a particular condition 
Interlocks-and-Protection : is present 
Interlocks-and-Protection-->Safety-Systems

Safety-Systems : Safety systems are used for both machine and personnel 
Safety-Systems : protection emergency stop systems for example
Safety-Systems-->Calculations

Calculations : Perform any discreate calculations required by the process, 
Calculations : this may be mathematical calculations, timing calculations 
Calculations : or even logical calculations
Calculations--> Continuous-Control-Logic

Continuous-Control-Logic : Continuous control is the constant monitoring and evaluation 
Continuous-Control-Logic : of plant devices and process variables. The continuous control 
Continuous-Control-Logic : logic assesses the condition of the plant and generates actions 
Continuous-Control-Logic : to produce the required process conditions.
Continuous-Control-Logic-->Sequential-Control-Logic

Sequential-Control-Logic : Sequential logic operates in a series of successive steps, 
Sequential-Control-Logic : each step carrying out an action and waiting for transition 
Sequential-Control-Logic : conditions to be satisfied before moving to another step. 
Sequential-Control-Logic : Sequential logic is often triggered by the continuous logic 
Sequential-Control-Logic-->Command-Execution

Command-Execution : Both continuous and sequential control logic generate actions, 
Command-Execution : these actions require something to happen, e.g. a valve to open, 
Command-Execution : a drive to start etc. 
Command-Execution : The command execution blocks martial these signals and trigger 
Command-Execution : the appropriate response (issues the command). 
Command-Execution-->Device-Drivers

Device-Drivers : ● Control loop device drivers operate and monitor the PID loops
Device-Drivers : ● Valve drivers operate and monitor all forms of valves
Device-Drivers : ● Motor drivers operate and monitor all forms of motors and drives
Device-Drivers-->Messages

Messages : Handles Controller messages e.g. alarms, warnings, events and 
Messages : prompts that require some form of user interaction
Messages-->Communications

Communications : Executes any system-to-system communications e.g. Controller 
Communications : to Controller and any other form of communication
Communications : required by the system e.g. point-to-point serial communications,
Communications : ProfiBus field messaging etc.

Figure 1.1 — PAL software execution chart

The above list is the complete PAL programme structure, not all Controller programmes will have all these steps (it depends on the application in question). However, where a step is used, it must follow the execution order shown in the above list.

For example, if a programme did not require interlocks or safety, but had instruments and continuous logic, then the continuous logic would follow the read instruments (interlocks and safety would not be present); continuous logic must not precede read instruments in the order of execution.

Each of the points in the above list will generally have an application block and, usually, at least one standard module associated with it; (there are some points, command execution being one, that do not have any associated standard modules).

⬆️ Top

1.1.2 The standard modules

The standard modules cover the following aspects of the control system:

System (internal) signal generation
Instrumentation
Safety and interlock systems
Calculations
Sequence operation
Device handling (control loops, valves, drives &c.)
Messages
Communications
General purpose subroutines
Debug functions

In the context of this Project standard modules are software modules that will carry out a particular function; an example would be a module that controls the operation of a valve, such a module would typically do the following:

Open and close the valve when commanded to do so
Determine if the valve is in a fault condition (i.e. the valve did not open when re-quired to do so)
Provide status information about the valve allowing other systems (SCADA, HMI &c.) to display the condition of the valve (i.e. opened, opening, closed, closing, fault, interlocked &c.)

The module would be configurable to accommodate different types of valves and signalling arrangements:

Different arrangements of position feedback (none, open only, closed only or both open and closed)
Different opening and closing times
Handle external fault signals (typical for motorised valves)
Accommodate different energising states (i.e. energise to open or energise to close)
Manage different interlock arrangements and signals

The module would also determine how the operator could interface with the valve:

Provide manual control (operator can take direct control of the valve)
Restrict specific manual control function (this ranges from full control using simulation to override faults, to no control whatsoever, even restricting the display of faceplate interfaces)
Allow or restrict the operator from changing operating parameters associated with the valve

Similarly, an instrument read module would do the following:

Read an analogue instrument signal received via an analogue input card and scale it to the correct engineering units
Generate alarms and warnings whenever the signal is beyond a specific target value (either above or below);
Alarm or warning may be time filtered (the condition must be present for a preset time before the alarm or warning is activated) and each will automatically reset when the signal is back within the acceptable range by a hysteresis amount.
Generate out-of-range fault signals if the instrument is outside its normal calibrated range by more than a specified amount

⬆️ Top

1.1.3 The user interface

Although supervisory systems such as SCADA and HMI systems are outside the scope of this Project, the interface between these systems and the PAL software modules is not; and this must be clearly defined in order to provide the necessary signals to display and interact with the any supervisory system.

The interface between a supervisory system and the PAL software modules will be detailed in this document and will include example graphics that may be adopted by any supervisory such supervisory system.

The interface will be different for different types of equipment (the interface to an instrument will for example be completely different to that of a valve); however, a commonality of approach (and where possible, signals) will be adopted to give consistency to this interface.

⬆️ Top

1.1.4 Templates and documentation

A series of template and documentation modules will be provided to give worked examples of how the PAL software modules should be used in a control system project.

Template modules

The template modules explain how to use and deploy the various standard and application modules and also the many organisation blocks (OBs) that may be required in various circumstances. The template modules provide detailed example usage for the standard/application modules and demonstrate different operating modes and configurations.

The template modules will be fully commented and will apply all the correct formatting and styling required by the PAL.

Documentation modules

The documentation modules contain summaries of the various styles and comment formats that can be copied and used within the software modules. These are essentially quick reference (proforma) guides that can be used as the outline for application modules &c.

⬆️ Top

1.2. Background to the Project

The Practical Series of Publications has, for some time, had a partially developed set of standard library modules that have been used on various projects in the past.

Over recent years, there has been an increasing amount of such projects and it has been decided that these partially developed modules should be expanded to include a full range of standard modules and that modules should be formally structured into a software module library: the Practical Series Automation Library (or PAL).

There has been an increasing amount of pharmaceutical work in recent years and the necessity to reduce testing time and costs within these projects has been recognised; to this end the Practical Series Automation Library software module will be fully tested and validated, removing the need for the extensive design and docu-mentation stages and the formal testing stages This will already have been done (and written) as part of this Project and will be issued in verifiable form by this Project.

⬆️ Top

1.3. Regulations and standards

The environments within which the PAL software can be used include pharmaceutical applications; as such the software must be written to the standards necessary for Good Manufacturing Practice (GMP), generally referred to as GxP².

The Validation Plan VP provides a justification and determination of validation requirements of this Project. The result of this determination is that this Project is a category 5 “bespoke” system and will comply with, and be written to, the standards necessary for GxP. These are the most rigorous standards used for control systems software and hardware development and use.

The GxP requirements are encapsulated in the International Society for Pharmaceutical Engineering (ISPE) guidelines, referred to as Good Automation Manufacturing Practice (GAMP), currently at revision 5 (GAMP 5). Systems that are written to the standards in (GAMP 5) are said to be compliant systems that can be validated.

Validation is the process of making sure a computerised system (such as a PLC and its software) does precisely what it was designed to do; specifically, it is the exercise of correctly and traceably documenting every requirement of the system and making sure that that requirement is formally and exhaustively tested.

This Project, the Practical Series Automation Library, will be written to the standards specified in (GAMP 5), it will be a validated and fully compliant GMP Project. The precise details of the validation process are specified in the Validation Plan VP document.

Note

² GxP is a general term for good [something…] practice, where the x stands for various things, manufacturing, distribution, laboratory, clinical, engineering, &c.

⬆️ Top

1.4. Assumptions and limitations

The Practical Series Automation Library of software modules will be developed as part of this Project. The scope of this development will be limited in this Project to just the Controller software, it will not include a library of supervisory control and data acquisition system (SCADA) or human machine interface (HMI) graphical objects.

The software will be written to interface with such system in a common manner, but the SCADA and HMI system will not be developed as part of this Project (though it is envisaged that this development will take place in a future project).

The PAL software will be validated to the GxP requirements that are applicable to the United Kingdom at the time of writing.