0.1.1 What it is.

The Java PLC is a project or collection of projects intended to provide a functional PLC (Programmable Logic Controller), initially intended for academic, instructional and experimental use.

This Project really began in late ~R96 early ~R97. I had just taken a course in C++, and had reacquainted myself with the Siemens S5 PLC and the wonders of the Step 5 programming software. Looking at the S5 instruction set, and the way the application code was executed I decided that it would be a good application of the object-oriented techniques I had been learning.

The initial work I did was no more than jotting down a few requirements and drawing up a few class specifications.

The initial objectives were to create PLC emulation on Windows with DDE and OLE access to the data tables. The program was to be developed in C++ using object-oriented techniques.

There were to be four major milestones.

• Complete emulation of the Siemens S5-102U instruction set.
• Complete emulation of the Siemens S5-115U CPU 945 instruction set.
• IEC 1131-3 (IL) compliant emulation.
• Translators to provide conversion from Mitsubishi, Omron, S5, PLC5 and SLC5 exported text files.

The goals today are a little different. The advent of the LinuxPLC (LPLC) project has inspired me to change the goals somewhat. The new project is intended to compliment work carried out by other contributors to the LPLC.

New objectives are:-

• Platform independence ~V initially Linux and Windows
• Open Source - GPL
• Leverage and compliment the LInuxPLC project. The intention is to interface with the various products (I/O drivers, HMI~Rs,etc) of the project, and to provide ideas and prototypes for use by other project contributors.
• IEC 1131-3 Compliant (as far as possible)
• Connectivity and Compatibility.

The original intention to use Object Oriented techniques remains, the development language of choice is now Java.

Java is chosen for a number of reasons including;

• Portability
• Ease of use
• Object oriented
• Network capable
• Supports additional personal objectives.

There are two (at least) personal objectives to this project, in addition to those given above. These are;

• Consolidate knowledge and understanding of Java.
• Learn the application of (the) UML in the design of object oriented systems.

Additionally, parts of the project may be used or referred to in my masters thesis.

As this project is a spare time project, currently without any defined deadlines, a formal project schedule is not provided. This may (and probably will) change as the project evolves.

Where features can be planned the will be assigned to a given implementation rather than a defined time scale, e.g. "FB~Rs with passed parameters will be included in the second iteration, online edit capability will be included at version 3".

Various projects are proposed to support and compliment both the jPLC and LinuxPLC projects.

Some of these projects overlap, for example, the project database will be of use in all of the proposed projects.

This is the main part of the current project.

This involves the development of a Virtual Machine or Virtual PLC. The VM will contain data tables, logic solvers and communications mechanisms. It is intended that the architecture will be compatible with the IEC 1131-3 software architecture.

It is envisaged that the VM will, initially be used in an academic, training or testing environment. It is hoped that the system(s) produced by this project will be of use to the LinuxPLC project.

The VM will execute tokenised 1131-3 Instruction List (IL) statements. The statements will be loaded into the VM from a compatible text file or via text terminal input.

Later projects will generate editors in a format that will allow conversion to the native format (IL), and project managers to ease the application development burden.

Native support for state transition logic in the form of grafcet/SFC will be provided later.

Native support for other languages may be provided as time and performance dictate.

It is intended that this system will support existing development tools (see Program Editors) and tools will be provided (eventually) to allow the translation of output from both IEC compliant tools and the text output of proprietry tools such as RSLogix (AB), S5 for Windows (Siemens) and Syswin (Omron).

The intention of this project was/is to provide a stream based multi - I/O server for use by HMI, SCADA and business connectivity applications. (future)

This server is to support a number of external connection types including (but not limited to):-

• class method invocation
• TCP/IP Sockets
• CORBA
• stream

Connections to the I/O will be by stream, protocols will be defined to decorate the streams.

The intention is to provide editors for all of the IEC 1131-3 languages. (future)

• IL ~V Instruction List (native)
• LAD ~V Relay Ladder Logic (RLL) (translated)
• FBD ~V Function Block Diagram (translated)
• SFC ~V Sequential Function Chart (Grafcet) ~V (translated/native)
• STL ~V Structured Text Language (translated)

Editors/translators for other, non-IEC languages may be provided (future)

Translators for existing development tools will be provided as appropriate. (future)

These will initially be

• S5 for Windows text export.
• Omron Syswin text export.
• Step 5 ~V print to file listing (statement list only).
• RSLogix5/RSLogix500 text export

All translators will be bi-directional where possible.

A number of project management tools will be developed. (future)

It is intended that the results of this project will be an extensible integrated engineering environment. The resulting environment should integrate all project lifecycle stages proposal and quote, specification (system, hardware, software), implementation (wiring, logic, HMI), test (emulation, simulation) and maintenance (change control, version management, bug reporting/tracking).

Initial development will create applications that integrate to a project database/data dictionary. (future)

Development will use object-oriented methods.

The actual methods used, and the way in which they are applied may support internet based development.

From the outset I considered an incremental, iterative approach to be essential.

I initially considered using a modified spiral model, however, I believe the RAD or JAD development model is better supported by internet/Open Source community development.

The RAD model will be used therefore until/unless a better or more appropriate model is made known to me.

The development language is to be Java with design in (the) UML.

The Java language was developed by Sun Systems for use as a platform independent, object oriented language for the implementation network based applications.

Applications consist of a number of tokenised modules (classes), which are interpreted on a virtual machine (JVM). Various JVM~Rs are available for various different platforms (e.g. Sun and Blackdown for Linux; Sun, IBM and Microsoft for Windows, etc.

I intend to use 100% pure Java where possible, to Java Platform 2 for development, however, wherever possible code will be JDK 1.1.6 compliant. Java technologies, such as Beans and JDBC will be leveraged wherever appropriate.

Java native method invocation (JNI) will probably be required for I/O driver interfacing.

There are a number of reasons for selecting Java as the language of choice. These reasons range from the personal, it is the language that I have most recently learned; to the pragmatic, it supports relatively easy development of modular, object oriented applications.

In theory at least, modules can be replaced with improved or just different ones simply, without recompiling, just by changing the class file (providing the access method signatures do not change). This would enable, for example, the swapping of a data exchange protocol or an I/O driver just by closing down the JVM unplugging the existing class and plugging in the replacement class.

Java is portable. To some extent Java applications can run on anything from Sparc Workstations to the Psion Series 5MX (and may be even the next generation of mobile phone).

The main downside of Java is the performance issue.

Here, the strengths of Java ~V late binding, garbage collection, the portability afforded by its interpreted nature, provide a weakness.

Garbage collection attacks both performance (speed of execution) and determinance (repeatability of execution). Garbage collection ensures that memory is returned to returned to the operating system when it is no longer used by the application e.g. when a thread ends, or an object is deleted its memory is de-allocated automatically.

The concept of running a virtual machine or interpreter (jPLC) on top of another (JVM) on top of an operating system does seem a little strange at first, however, it is not as rare as one might think (VMWare, VIM) especially where portability issues are concerned.

The real time Java specification has been developed to address some of these points. In addition, many Java development kits allow for compilation to native code, and there are many Java to ~E translators.

The actual performance and optimisation of the jPLC, are considered by me to be a main part of the project.

Part of the objectives for this project is for me to learn to apply the UML.

I intend to provide specifications and design documentation in the appropriate UML notation. As I am far from an expert, I would appreciate patience and any constructive feed back appropriate to my use of the UML.

Apart from the JDK 1.2 (Java 2 Platform) tools, I will be using a number of other tools. Wherever possible these tools will be zero or low cost.

These tools fall under a number of headings.

Version control will be carried out using CVS.

Program editors fall into two categories text editors and IDE~Rs, on two platforms Windows and Linux. The Windows editors that I use regularly are EditPlus (shareware - $20), and PFE (freeware). (I am not yet familiar enough with the Linux editors to make a similar choice). The IDE(s) of choice, I would like to be platform independent. There are a few Java IDE~Rs written in Java that apparently run on both Linux and Windows. I will investigate FreeBuilder, ElixirIDE and BlueJ.

CASE tools will again be platform independent. My preference would be for TogetherJ (this is GOOD) however the full product is very expensive and the Whiteboard Edition doesn~Rt allow for drawings to be printed, controlled or exported. Also, it only supports Class Diagrams.

Plastic is also easy to use, is cheaper though still expensive. ElixirCASE Lite is a free download, it is not as easy to use and I am not sure yet what limitations it has.

[If I can find $4000 I~Rll use Together <ouch!>, if I can learn how to use it I~Rll use Elixir.]

The documentation standard for the project will be HTML (XML may become the standard later on).

Source code annotation will be in a javadoc compatible format, all jPLC code documentation to be updated and released at the same time as the source.

All documentation will be (at least after the first issue of code) version controlled.

Documents will be in simple, hand coded (or codeable) HTML.

All drawings and pictures will be as small as possible (file size), there will be no sound or video files. Where possible, pages will be optimised for download.

All features will be documented in a standard way and include standard information.

This information will include, where appropriate,

The version number is represented using the following convention.

<Version Number> .<Increment Number>.<Prototype Number>x

Where x can be

Coloured text will be used, except in automatically generated documentation, to denote changes from the previous release.

Grey text will denote removed text.

Magenta text will denote added text.

Green text will denote modified text.

Red text will denote important notes or comments.

The purpose of this document is to provide a statement of requirements for a software Programmable Logic Controller (PLC).

The PLC will allow for the usual PLC functions and will solve application logic in a solver engine or virtual machine. Where possible the PLC will remain IEC 61131-3 (1993) compliant. Extensions to the IEC standard will be available to the user where appropriate.

Unlike most statement of requirements documents, this document will include discussion on the implementation.

The system will be modular and extensible.

The software architecture is shown in the following block diagram.

Fig. 1.3.1 Software Architecture Block Diagram.

When the PLC is started (the softPLC is loaded into the PC memory and execution begins), a PLC image is loaded into memory. I/O and data table memory is initialised.

When the PLC moves into the RUN state the all inputs are moved from the I/O table into the data table, the engine then begins solving the logic. When all the logic has been solved the outputs are copied from the data table to the I/O table. The logic solve cycle, or program scan then begins again.

The logic is solved starting with the function block referenced by the InitialFB register.

Housekeeping tasks a carried out in parallel with the logic solve cycle. These tasks involve timer update, system information upkeep and monitoring.

A separate process is concerned with communications and security. A TCP/IP communications server is provided to allow communication on several ports. Connections can be made to the server for downloading application software, editing and monitoring the operation of the software, data acquisition, alarm annunciation and other functions as appropriate.

The security module prevents unauthorised access to restricted functions as appropriate.

The PLC has a number of operating modes;

Table 1.4.0 PLC Modes

The data table will be implemented using a vector table of vector tables. Currently only one, two dimensional data table is supported. This table is local to the PLC but global to all function blocks, networks and statements contained by the PLC. Function Block scope variables are not currently supported.

A vector is a special case of an array, which resizes itself automatically as required.

Table entries will be implemented as objects.

Each data type will be stored in a different vector table. (see Addressing).

The following data types will be supported. (Some data types will not be available until later releases of the package).

Derived data types, structures, and arrays are not currently supported.

Table 1.4.1 Supported Data Types

Type checking can be implemented in a number of ways.

Firstly, strict type checking can be applied such that the mixing of types is considered to be a fault condition and an exception is thrown whenever type mixing occurs.

Automatic promotion and demotion can be applied. If a variable of one type is copied to a variable of another type, the result depends on the size (number of bits) in each of the variables) e.g.

Copying from a smaller sized type to a larger sized type results in the contents of the smaller type being copied to the larger type (bit justified to the lower significant number of bits). If a larger type is copied to a smaller type the lower significant bits are copied, excess bits are discarded.

Currently, strict type checking is enforced.

Addressing of data table entries will be as per IEC 61131-3 (1993), with extensions.

There are two types of addressing, direct addressing and symbolic or tagname addressing.

Direct addressing, addresses program variables by their data table location. IEC 61131-3 denotes directly addressed variables by the use of the ~Q%~R identifier. The variable is represented by the ~Q%~R identifier, followed by a letter code, a modifier(optional), a table entry address or element number and a bit address i.e. %TMe.b.

Where, T = area designation, (IEC 1131-3, 2.4.1)

M = Variable modifier, (IEC 1131-3, 2.4.1)

e = the element number, (IEC 1131-3, 2.4.1)

and, b = bit number. (extension)

Supported type designations are as follows.

Table 1.4.2 Type/Memory Area Designations

Table 1.4.3 Type Modifiers

Tag name addressing is the IEC/PLCOpen preferred method of addressing. Here the variables are addressed in the same way as High Level programming languages, by the tag name identifier. Tag names can be assigned to a direct address in the variable declaration.

Currently only direct addressing will be supported. Tag name addressing, with auto/anonymous assignment will be supported in a future release.

Auto assignment assigns the next available direct address of the correct type to each variable as it is declared. Auto assignment can take place in either the program development software or on compilation.

Anonymous assignment is auto assignment which takes place only on compilation. In this case the assignment is hidden from the user and subsequent downloads may assign different memory to the same variables (though it is probable that if no changes have been made the assignment will be the same).

Indirect or Indexed addressing has been found to be useful in the past. If possible these types of addressing will be supported in the future.

Variables are declared in the source code using the IEC 1131-3 notation.

As with all IEC 1131 declarations, the declaration is surrounded by block delimiters, in this case VAR and END_VAR. For example,

declares two variables, a real variable with the identifier (tag name) max_speed, and an integer, mode.

Different types of declaration can be made. The following table shows the declaration key words for various variable groups.

Table 1.4.4 Variable Declaration Keywords

Variables can be assigned a memory location when declared. This is done using the AT keyword e.g.

declares the input, stop, at input address %I1.1.

Note: the bit address in the above example is an extension to 1131.

Variables can be declared at any point in the source file providing it is not within a code block declaration. Note that local (FB scope) variables are not supported.

Although the earliest issues of the PLC are not expected to interface directly to I/O, it is worth some discussion on the requirement and implementation of the I/O.

First a definition of I/O in terms of the jPLC is required. I intend to define I/O at this point as the direct data interfacing with processes external to the current (this) instance of the jPLC . This may include the interfacing to real world I/O, other logic engines, I/O servers or HMI/SCADA applications.

It is intended that this interface will connect to the Shared Memory Model supported and proposed by the LinuxPLC project. It is also intended that in (the far) future the I/O interface will support a number of connection methods.

As I/O drivers deal directly with hardware, these drivers will not be written in Java and will be platform dependant. The intention is to define a standard interface, which will allow alternative drivers to be used.

The I/O space from the PLC~Rs view will consist of two word tables, inputs and outputs.

The PLC will NOT be concerned with the mapping of I/O to physical devices.

The PLC will, probably, use Java Native method Invocation (JNI) to access an external driver to perform I/O update.

Input Table Update:

Output Table Update:

The actual implementation will depend on the limitations of JNI and any requirements issues. At its simplest the input update method passes the length of the input table, len, to the driver along with the PLC~Rs desigantion. The driver should then return an array IList[] containing the input data. The output update method is passed the PLC designation, the output table as an array and the length of the array.

The driver uses the PLC designation to determine, from the I/O configuration, which inputs need to be returned and which outputs need to be set.

Forces are provided as a maintenance feature. Forces are a part of the PLC function and can force an output or any number of outputs to a predetermined state. The I/O driver/server/engine does not need to know anything about this.

Inverts may be provided as a convenience. An inversion is a function of the I/O engine and can reverse the state of a boolean I/O point. The inversion is transparent to the PLC, which does not need to know of its existence.

The logic engine solves the logic programmed in a list of tokenised instructions or statements.

A statement is an object which consists of several fields, the fields of most importance to the solver are the label, operator (with its modifier(s)) and operand.

The label is use as a target for program flow control operators (jumps).

The operator contains a token which represents an IEC 1131-3(3.2) instruction list (IL) command along with its modifiers.

The operand is the data on which the operator performs its operation.

Execution of the operator will monitor and/or modify the contents of the result object. This object stores the result of previous operations for use with the current one.

The following table shows the supported operators and their tokens (op code).

Table 1.5.1 Instruction Set

The application program for the PLC is organised in a hierarchical modular manner compatible with the program organisational units defined in IEC 1131.

The smallest unit of the program is the statement. The statements are executed in order one after the other. Program flow is from the first statement to the last unless otherwise defined by use of JMP, CAL or RET.

Statements can be grouped into Networks. The Networks are executed in order one after the other. Program flow is from the first Network to the last unless otherwise defined by use of JMP, CAL or RET.

Note: The Network is a kin to the Modicon and Omron objects of the same name, and the Siemens segment.

Statements and/or Networks can be grouped together in function blocks (FB). Function Blocks are only executed when called by the use of the CAL instruction in a statement.

Function blocks can be nested, and there is no predefined level of nesting.

Parameter passing is key to the use of function blocks. (future)

There is at least one function block within a PLC, this is the initial function block which the PLC calls on start up.

Programs are declared in a text source file.

The initial function block can be declared in a number of ways.

The preferred method is to declare a PROGRAM. The program may have function block declarations embedded, or may call other function blocks declared externally but within the same source file (the use of multiple source files may be developed in future).

(Only one program declaration per PLC will be supported initially).

In the absence of a PROGRAM declaration, the compiler will accept function blocks with the following names as the initial function block, in order of preference;

• INIT
• MAIN

Declaration, as with variables, utilises a BLOCK/END_BLOCK structure, i.e.

BLOCK BLOCKNAME

some statements

~E

~E

~E

END_BLOCK

So a program might be declared as follows,

PROGRAM MIXER

LD %S1.1

CALC STARTUP

CAL WEIGHING

CAL MIXING

FUNCTION_BLOCK WEIGHING

weigh some ingredients~E.

..

..

..

RET (* As the last statement in an FB RET is implicit *)

END_FUNCTION_BLOCK

END_PROGRAM

This might be followed in the source file by;

FUNCTION_BLOCK MIXING

mix some ingredients~E.

..

..

..

END_FUNCTION_BLOCK

An option is to store program comments and annotations with the compiled program in the PLC, this provides the ability of uploading fully documented source directly from the PLC. This does not affect the performance of the PLC, unless comments are displayed when monitoring, it does however affect the memory required by the application.

Comments can be entered into the source file either in

• IEC 1131-3 accepted format, i.e. (* ~E~Ecomment ~E~E.*)
• or in C++, Java short format, i.e. //~E..comment

In either case only single line comments can be stored in the PLC.

The compiler is built in to the download mechanism within the programming port. It is intended that this compiler is pluggable, which would enable various compiler options (all having the same final output). Indeed the default compiler may enable various notations to be downloaded transparently.

The compiler will be flexible and will recognise several variations on a theme, the preferred notation will however be IEC1131-3 compatible.

The download compiler will of necessity, probably use a multi-pass mechanism. The first pass will set up variable and function block references, the second pass will ~Qpopulate~R networks and statements. Additional passes may be necessary to resolve label references.

The compiler will have and incremental mechanism to allow online modifications to be made.

A decompiler function will be associated with the upload and monitor functions.

One or more TCP/IP servers will be provided to allow communications between the PLC and external applications. There will be at least two servers each with their own port number.

Table 1.6.1 Instruction Set

Additional communications paths will be added in future.

Additional ports that may be included are Error and Debugging ports.

The communications servers work in conjunction with a Security server, which ensures that only appropriate access is allowed (future).

Various systems and housekeeping tasks are undertaken.

These tasks include timer update, watchdog monitoring and built-in data flag update.

The system tasks include the update of the System memory area of the Data Table.

It is worth a brief discussion on timer update. The timer, as are all data types, is implemented as a class and is instantiated as an object. Timers are updated by timer events produced by special threads. These events cause the update of one or more lists of timers, each list contains timers which have been assigned a particular time base.

The initial idea was, on an update event, simply to increment an accumulator register, compare it with a preset register, setting status flags depending on the result. This would be simple to implement, however, it would not be particularly accurate as the event time would not be determinant.

An alternative implementation is to store the system time in the timer when the timer~Rs enable flag goes true. The update event would then check to see if the difference between the current system time and the stored system time was greater than the preset time. This would not have the possible creeping error inherent in the first method, it would also be closer and more easily convertible to the IEC Timer data type. It does however have it~Rs own performance issues and several compromises will have to be made in its implementation.