1Introducing 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 to be applicable to virtually all industrial applications that can generally be controlled by a programmable logic controller (PLC) or, to use Siemens terminology, a “Controller”^†.

†		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).

In general terms, the PAL software 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

• Material handling

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

These 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 (standard modules make 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 are fixed modules, the software within these modules has been written, tested and validated as part of this Project prior to release. Once released, the modules must not be modified or changed in any unauthorised way, to do so would invalidate the software.

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 (QP) 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

• Sequential control

• Command execution logic

• Device handling (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 application modules have been designed, developed, tested and issued as part of the Practical Series Automation Library Project.

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

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

Certain modules within the PAL library, have operator interfaces; typically, these are modules for reading instruments, managing equipment (drives, valves, loops) and controlling various aspects of the plant (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.) do not form part of this Project, the interfaces (and to some extent the expected appearance of the graphical symbols that would be used in such systems) are defined.

The requirements for this Project were defined in the User Requirements Specification (URS), and were, broadly, 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:

1. Determine the overall structure of the software that is to be used as the basis for all industrial application deployments, this forms the basis of the required application modules

2. Determine and build the standard modules that form the library

3. Design of the end-user interface for those modules that require such an interface

4. Build a series of template and document modules that 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 following sections:

The software within a Controller is generally structured in a logical order; that order is generally, to read data provided to the Controller, process that data, and to then act on that information by changing the state of some part of the plant.

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:

1. Read the tank level instrument

2. Evaluate the level (is it above the target level)

3. 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 have been adopted within the PAL.

The PAL will broadly adopt the following overall software structure (Figure 1.1).

This shows 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 Figure 1.1.

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 Figure 1.1 will generally have an application module 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).

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 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

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.

The interfaces between a module and a supervisory system are clearly defined for each module 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 is specified in detailed and includes example graphics and interface logic that should be adopted by any supervisory system.

The supervisory system interfaces are different for different types of equipment (the interface to an instrument is different to that of a valve); however, a commonality of approach (and where possible, signals) has been adopted to give consistency to this interface.

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.

The template modules explain how to use and deploy the various standard and application modules 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 are fully commented and apply all the correct formatting and styling required by the PAL.

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.

The Practical Series of Publications had, for some time, 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 was decided that these partially developed modules should be re-developed using the latest technology and 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 was recognised; to this end, the Practical Series Automation Library software module has been fully tested and validated, removing the need for the extensive design and documentation stages and the formal testing stages This already having been done as part of this Project and issued in verifiable form by this Project.

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.

• Note: GxP is a general term for good … something … practice, where the x stands for various things, manufacturing, distribution, laboratory, clinical, engi-neering, &c.

The Validation Plan (VP) provides a justification and determination of the validation requirements for this Project. The result of this determination is that this Project is a category 5 “bespoke” system and the software produced as part of the Project has been written to comply with the necessary standards for GxP. These are the most rigorous standards used for control systems software.

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, has been written to the standards specified in GAMP 5, it is a validated and fully compliant GMP Project. The precise details of the validation process are specified in the Validation Plan (VP).

I am a chartered engineer and I’ve been doing this stuff for a long time. In the course of my career (if that’s the right term) I’ve come across a lot interesting projects and, generally, I’ve had an enjoyable time being an engineer, I like it. There are somethings I don’t particularly like, Project Managers for example.

There’s an old joke:

There’s a man flying in a hot air balloon and suddenly he realises he’s lost. Reducing height, he spots another man on the ground and shouts “Excuse me Sir, can you tell me where I am?” The man below says: “Yes. You're in a hot air balloon, hovering 30 feet above this corn field”. “You must be an engineer” says the balloonist. " “I am” replies the man. “How did you know?” “Well” says the balloonist, “everything you’ve told me is technically correct, but It's of no practical use at all”. The man below thinks for a while and then replies, “You must be a project manager”. “I am” replies the balloonist, “How'd you know?” “Well” says the man, “you don’t know where you are or where you’re going, but you expect me to help. You’re in exactly the same position you were before we met, but somehow now it’s my fault”.

I am that engineer.

Unfortunately, there is another class of manager that is even worse: Validation Managers. These are politely and respectfully referred to as “Felchers^†” by engineers everywhere. They live in pharmaceutical companies (when they’re not in cloud cuckoo land) and are a right pain in the arse.

†		Felcher [noun, slang] A well-established term in the Engineer’s Lexicon of Insults. Er… if you are of a squeamish nature, I shouldn’t look it up.

They are the Jeremy Corbyn supporters of the pharmaceutical world: entirely convinced of their own moral superiority and completely dismissive of any other argument. They have a stifling certitude; an implacable self-righteousness and they are always, always willing to be offended (I imagine they would fit right in on social media).

The regrettable thing for engineers, is that these validation managers have some power (and by God are they pissed with it) and they can make life difficult if you don’t jump through their hoops.

The problem is, I want my software to be usable in pharmaceutical systems, after all a valve is a valve whether it’s in a pharmaceutical plant or a water treatment works, it opens and it closes. This means that the software has to be validated.

Validation, in terms of “it’s a validated system”, 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.

If you haven’t come across the term before it probably means you haven’t been working in the pharmaceutical industry — but don’t worry, other industries are looking at it and starting to think it’s a good idea. Not only is it springtime for Hitler and Germany, it’s looking pretty good for the validation people too and some of them make Hitler look like a walk in the park.

If you are an engineer, validation will be coming soon, to a town near you! — It’s time to get dressed and saddle up.

Validation usually involves a lot of signatures in black ink and a lot of stern looks from the validation people (particularly if you don’t write the date the correct way), validation people don’t smile much in my experience, they are not party people — think Nurse Ratched

Two validation managers were asked to validate the company flag pole to make sure it matched the correct height requirements. They go out to the flagpole with ladders, string and a tape measure, but they’re struggling to reach the top and can’t get the correct measurement. Two engineers passing by see what they’re trying to do, the engineers walk over, lift the flagpole from its footings, lay it flat on the ground and measures it from end to end. The engineers put the flagpole back, give the measurement to the managers and walk away. After they’ve gone, one validation manager turns to the other sniggering “Isn’t that just typical of engineers? We’re looking for the height and they gives us the length.”.

Validation itself is fairly straight forward; it is to some extent exactly what you would do yourself if you knew nothing about it. If you were writing some PLC software to do something, you would probably have a document that explained what the PLC was to do: open a valve when the level reaches this value; and you would probably write a document to test the function: did the valve open when the level reached that value?

Easy — this is what engineers have always done. We don’t just build something; we build it and then test it to make sure it works properly. We didn’t just build the Apollo rocket and fire it into space, we blew lots of them up first, figuring out how to fire it into space.

Engineers have always tested things, we’re conservative, we assume we’re going to cock it up the first few times and we test and we test until we get it right. Pharma people — not so much — think Thalidomide; Thalidomide was considered safe because they couldn’t find a dose high enough to kill a rat without squashing it and it sold in nearly the same quantities as aspirin before they realised something was wrong.

I understand why pharma people are nervous (once bitten and all that) and why they want to get it right, the nuclear industry does it for the same reasons (just watch Chernobyl if you want to see engineers really screw something up).

What I don’t like is the secrecy that surrounds validation, it’s a bit of a club where those in the club don’t really want to explain it to those outside; they say they do (because it’s supposed to be open and transparent), but they don’t. There’s lots of information but it’s all designed to be a bit intimidating and to make you feel, well, stupid. I found the same thing when I looked at Git and version control systems. It reminds me very much of the gramophone sketch by the Not the Nine O’clock News team. It’s the same attitude.

Lots of people make a living out of validating systems and they do so by overcomplicating it, everything is abbreviated (ICH Q9, GAMP, FEMECA) they use opaque terminology and jargon (component realisation, lifecycle support, white box, black box, pharmacovigilance), it’s how the medical and legal professions protect themselves from outsiders. Er… engineers aren’t blameless in this department either.

Validation itself is a good idea; it’s not a bad approach to take to every project — sometimes it’s required (pharma, nuclear, oil and gas), sometimes it’s completely over the top (PLCs playing the trombone^†), but most projects benefit from the approach (even if they tone down the rigour and rules a bit; most projects don’t care how you write the date or make sure you draw a line through every blank area on a page).

†		When I worked for Siemens, we had a demonstration project to show the capabilities of a PLC. We decided to make one play “I’m forever blowing bubbles” on a trombone. It had an air compressor connected to the mouthpiece and a three-phase motor driving the slide and it was bloody loud (engineering at its finest).

It also occurred to me at this point that the project itself, with all its documents, specifications, matrixes, test sheets and a practical approach to validation might be of use to some engineers too. It is a very good example of what documents are needed for a validated system, what should be in those documents and the correct form of wording to use.

So, I’ve made it all available I even explain how to structure all the folders on a hard drive and where to keep everything.

There is a complete copy of everything, including all the signed test sheets (with the date in the correct format to keep validation managers happy — happy is probably the wrong word).

Michael Gledhill
Chester—February 2025