Ada for Automation

Historically, automated systems are managed since the 1980s and the advent of microprocessors by specialized computers which are designated by the term Programmable Logic Controller or PLC.

The system to control, a machine, a chemical reactor, biological or nuclear, any craft, has sensors that allow to know at every moment the state of the system, and actuators that enable to act on it.

The sensors provide binary information following Boolean logic, true or false, hot or cold, open or closed, etc. or information about a measured quantity, temperature, pressure, speed, Analog said, and in fact is a physical quantity converted into an electrical signal that is digitized in order to treat programmatically.

At that time, the controllers received their information or controlled their actuators with electronic cards arranged in a chassis that provided both a mechanical and electrical protection against electromagnetic interference.

The processing unit or CPU (Central Processing Unit) also lived in the same chassis or rack. One could extend the chassis via expansion flat cables and so have more inputs to acquire signals, and outputs to control actuators.

Each sensor’s information is given by switching a 0 voltage - from 24 to 48 or even 110 volts for the digital inputs, or by generating a signal 0 - 10V for a voltage input, 0 - 20mA or 4 - 20mA current input.

The actuators are controlled either binary, via relay cards, power transistors, triacs … or by sending an analog signal 0 - 10V, 0 - 20mA or 4 - 20mA to a regulator, a dimmer, a drive…

On a large installation, the controller chassis occupied a prominent place in the control cabinet and the amount of cables needed was proportional to the amount of connected sensors and actuators. For a sensor, a cable for the signal and a power cable, which could supply several sensors optionally, were necessary. For actuators, as it is possible to have a cable for analog signals, say the speed to be specific, a cable for digital signals, power / stop control as example and of course the power cables, cables installers had work.

All these cables have a cost, to purchase, in studies, implementation, and maintenance, knowing that the connectivity problems represent about 80% of the failures.

In the 1990s, it began to appear as fieldbuses Modbus or PROFIBUS.

A fieldbus is a cable, it is said a medium when it is a specialist, which runs from equipment to equipment, and which operates a communication between these devices according to a communication protocol.

As there are always multiple solutions to a problem, it has established a number of protocols, a new Babel.

On this fieldbus can be encoded signals from multiple characteristics to achieve transfer those signals with a good performance and an ever lower cost, performance agreeing by various criteria such as flow, speed, resistance to disturbances, distance, safety … Every compromise reached has its supporters and detractors.

To develop, standardize and promote each of these technologies, organizations are put in places.

On this fieldbus therefore, new communicating devices are emerging, from modules with inputs and outputs allowing local deport of the acquisition and control of sensors and actuators, but also drives for controlling motors, dimmers, all kinds.

Supply and fieldbus are enough to control installations by PLCs whose processing capacity increase accordingly.

Always looking for higher performance and cost reduction, the industry created since new protocols based on an affordable and efficient technology, the Ethernet technology. Of course, there is always a downside, and it took a lot amend this technology before it is suitable for process control applications.

As there are always multiple solutions to a problem, it has established a large number of new protocols, a new Babel …

These communication abilities are also benefiting to monitoring and diagnostic tools that can refresh the data faster and more transparent. They enable better availability of facilities and greater control.

One could mention the following advantages:

Mainframe computers were found since long to manage complex processes, blast furnaces, refineries … With proprietary operating systems, engineers for their administration and others for ongoing maintenance, these systems were not for everyone.

PCs invaded the offices but were confined to supervision as judged not reliable enough for the control and monitoring. There were many attempts but had bad press. They are reserved to the specific needs that require the processing power not available with processors powering the controllers or storage capacity or access to data in a database.

Since then, things have changed a bit, Linux has been there and reliability of operating systems has improved. The devices are also much cheaper and reliability is more important when choosing configurations without rotating parts.

The Mean Time Between Failure (MTBF) of an industrial PC is very close to that of a PLC, that said, it’s quite normal since they share many components today.

And providing scalability and openness incommensurate with the PLC, industrial PC has indisputable advantages.

When we needed a PC for supervision or advanced treatments, some have questioned why we would not do control-command with the computing power available, leaving the PLC.

We gain in cost, compactness, simplicity in architecture …

So we added some real-time extensions to general operating systems and developed automation solutions for the PC.

Siemens with WinAC® RTX® and real-time extensions from IntervalZero®, ISaGRAF®, CoDeSys®, ProConOS®, Straton®, TwinCAT®… Many.

It is possible to install I / O cards in the PC and thus obtain an architecture strongly resembling a rack controller. It is even the most widely used in many demanding applications solution.

It is also possible to install in the PC one or more industrial communication cards, such as those of the Hilscher company for example, to provide a connection to the fieldbus in master mode to control equipments or in slave mode to communicate with the upper level.

Control engineers are still somewhat reluctant to mix computers and automation. But times change, seniors are classed as oldfashioned by juniors grown up with Web 2.0, technologies are pushing the wheel and there is a convergence PC - PLC with an economic situation that compresses the budgets …

A control engineer or PLC programmer is a specialist in automation. It is asy to say, but it is a difficult task to explain what that means.

Depending on the area, chemical, petrochemical, pharmaceutical, manufacturing, building management, special machines …, his initial training, instrumentalist, electrician, mechanic, electrician, maintenance technician, the structure of the company that employs him, his curiosity and his inclinations finally, the standard automaticien profile is rather vague and extremely varied are his tasks.

It may be necessary for him to perform alternately several occupations on the same project. It is absolutely not unusual for a control engineer to carry out studies on instrumentation, electrical, automation and supervision, including networks and databases, etc …

Note that the computer science is not mentioned in his abilities. This is actually on the job and often a bit of obligation he learns it.

So a control engineer designs PLC programs, among other things but often has only some culture, and not a training, in computeur science.

Also, he has been concocted a range of languages tailored to his tasks, process of combinatorial logic, state machines, control or regulate quantities, monitor processes …

Thus we find:

All these languages have integrated debugging capabilities and dynamic visualization, which is very convenient, we must admit.

Moreover, it is usually possible to make online changes to the program, ie during operation of the machine without having to reset it, which is very useful when starting the installation. Of course, there are some caveats and some operations require recompiling the entire program, such as configuration changes, those relating to the interface of functions and blocks, etc …

However, these languages are adapted to the tasks of limited scope and their expressiveness is bad enough.

Once a Boolean equation is somewhat complex, the ladder networks become difficult to understand and it is even more difficult to develop them without introducing regression. The programs are miles long.

The logic diagram is gone, we have not heard a complaint.

Instruction list or LIST, pseudo assembler is as austere as the real assembler. Difficult to write, even more difficult to read it. The preferred language of my freelance colleague who said, "we must spoof the client". He succeeded the guy …

SFC or GRAFCET… So, especially in France.

With all these languages, that is if one is trained in their practice and their characteristics, we get to do things, especially if one chooses the most appropriate language.

Should they still be available. This is not the case in general, salesman gratify us with their drawer offers, and managers often have a short-termist view. Thus, such a workshop would propose that basic ladder, the logic diagram - useless, and instruction list.

As a smart manager, one will not, for example, invest in more advanced languages such as structured text or block diagrams because they offer higher productivity in many cases. Thus, the PLC programmers, who will not be trained and will not be able to train themselves because lacking the tools, will continue to develop in ladder or assembly language.

Over time, these same PLC programmer end up working as customers -the dream of every developer in software company- and impose their specifications the contact language or assembler. No functions or function blocks because it’s too complicated … It’s been lived.

In another development environment, we will not have the ability to write a simple function … Exasperating. We hear about object-oriented programming and we are not able to do only structured programming!

There are also systems in which more or less high level languages are used as C / C ++, Basic, Delphi and others. It’s pretty confidential but it is.

Visual Basic for Application that can be found in Microsoft Office® applications or in PcVue® supervision from Arc Informatique is also practiced.

"Ada for Automation", so this is a framework, ie open source code to allow you to write more easily and quickly own applications. With some success, this framework is expected to grow with time and contributions.

This application framework provides an environment where there are a number of elements such as execution loops, communication means to the inputs and outputs, but also to monitoring tools, libraries of functions and components …

It is necessary to add your application code to get something useful.

You will need to learn Ada, slowly but surely, to use it. However, the availability of source code will help you and if you know the ST language for "Structured Text" you will be surprised by a certain familiarity.

Ada is a compiled language, you will have to learn how to use the tools and debug techniques. Ada is a particularly powerful and elegant language, while remaining relatively easy to learn for a technician or an automation engineer.

En fait, celui-ci retrouvera dans ce langage les concepts qu’il manipule au quotidien en utilisant son atelier de programmation d’automate favori -ou imposé-, avec une syntaxe claire rappelant le langage "Structured Text" de la norme IEC 61131-3, ce qui est somme toute normal puisque ce langage s’inspire notamment de Ada. In fact, the PLC programmer will find in this language concepts he manipulates everyday using his favorite -or imposed- PLC programming workshop with a clear syntax reminiscent of the language "Structured Text" of the IEC 61131- 3, which is quite normal since this language draws particularly from Ada.

Some goals have been identified for this project.

Ada is a compiled language, with a performance comparable to that of the C / C ++. On current platforms, the performance obtained allows to consider the migration of a large majority of applications today running on controller.

Does this mean that "Ada for Automation" is opposed to the PLC manufacturers? Of course not!

On the one hand, most PLC manufacturers also have an offer "PC based Automation". This is particularly the case with Siemens WinAC ® on MicroBox and Nanobox for example, but also from Beckhoff, B & R …

Furthermore, in the event that "Ada for Automation" is adopted by a significant fringe of PLC programmers, nothing prevents PLC manufacturers to incorporate this possibility in their range. That’s also that free software!

Depending on the used hardware platform and operating system, the system architecture, the distribution of treatments, all applications are possible.

This may seem ambitious. The "Ada for Automation" project has for objective to provide an open platform for building automation applications. These are the users and contributors of the project, and of course the end customers, who will set their own limits.

However, this is achievable. The consum-actors are powerful entities that have an interest in seeing the establishment of standards, libraries of reusable components, good design practices.

One can also imagine a kind of vertical integration with "business" applications created by their users.

Other communities have been able to build in areas not so far away and got to shake the established monopolies.

Renovation or conversion of existing facilities are probably favorable phases in the evaluation / adoption of "Ada for Automation".

It is possible to save and reuse some, if not all, of the equipment and wiring equipping controller racks with fieldbus couplers in place of the central processing unit (CPU), I / O boards being maintained.

See for example the solutions developed by the company EFSYS: http://www.efsys.fr/

Thus, only the control part is to overhaul, which must be done anyway regardless of the chosen solution. The compatibility of the old software with the new material is more than rare and even if that were the case, or if converters allow to approach it, it is probably desirable to disentangle changes made in the lifetime of the facility under suboptimal conditions.

Since renovating, let’s do it right. We are working on the intelligence of the system.

"Ada for Automation" is an economical, powerful and durable solution for the realization of advanced control and monitoring applications.

Of course, we do not claim to revolutionize the field. The author is far from being an expert in Ada. It is even as a complete beginner he started developing this application framework.

And we know the resistance to change for having experienced them.

"Ada for Automation" is not intended to fans of a particular manufacturer / development environment / language. It is necessary to have some intellectual curiosity to overcome the acquired reflexes and venture off the beaten path. It will take some time for those interested to master the concepts and tools. But the concepts are universal and free the tools. We are certain that the benefits in terms of training and openness can be considerable.

We do not oppose automation languages and Ada. We think there is room for all. But we would be very happy if this language could find its place in the panoply of the automation engineer.

Ada would solve the problem of portability which is not yet resolved with PLCopen more probably due to lack of willingness of manufacturers than as a technical impossibility.

Maintainability has always been one of the major criteria in the development of Ada. The focus is on code readability because if it is written at least once it will be the subject of many proofreading.

It is obvious that the world of automation and industrial IT and those in which Ada is used traditionally share the same needs in terms of life expectancy, durability and reliability ot the solutions.

With a standard written in 1983 and updated in 1995, 2005 and 2012 incorporating the latest in Software Engineering occurred in the meantime and considered interesting by experts from the fields of use and language, Ada shows a good health. And it is still possible with the latest tools generation to compile applications written to the origin of language, even though they would still deserve a little bit of dusting …

We believe in the virtues of exemplary. If the fruits are good, is that the idea is good. This is the meaning, if not the formula …

We believe that we may be limited for "Ada for Automation" to use the basic concepts of language, so as to be more intelligible to non-Adaïstes. This does not limit the use of Ada for the user application.

We have long been committed to the ideas of free software and hope to contribute to the revolution with "Ada for Automation".

Freedom is a right in principle … but it must be deserved.

"Ada for Automation" is hosted by Gitorious :
https://gitorious.org/ada-for-automation

You can now obtain "Ada for Automation" with the usual git tools:

git clone git://gitorious.org/ada-for-automation/ada-for-automation.git A4A

or download an archive:
https://gitorious.org/ada-for-automation/ada-for-automation/archive-tarball/master

A Git tutorial is available here for example :
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

It is of course possible to contribute to this project:

A big thank you to all our contributors and in particular:

Aurélien MARTEL for the "Ada for Automation" logo

François FABIEN for his advice (francois_fabien@hotmail.com)

The project’s home page:
http://slo-ist.fr/ada4autom

The dedicated forum:
http://slo-ist.fr/forum/index.php

Hilscher France, author’s employer:
http://www.hilscher.fr/

You can learn a lot about Ada in French with the course of Daniel Feneuille (but you’ll have to learn French):
http://libre.adacore.com/tools/more-resources/ada-course-in-french

For those who think that Ada is accessible only to the cream of the University or High School, the course was designed for students of the IUT of Aix.

Without tool, man is not quite man.

If you’re on Linux, there’s a good chance that the tools are available in your distribution.

Look for GNAT in your Synaptic or equivalent.

Mr. Ludovic Brenta is doing an outstanding job as the maintainer Ada in Debian.

Thus, for example Synaptic enables you to easily install gnat-gps packages, gprbuild and their dependencies.

Whether you are on Linux or Windows or other AdaCore provides all the necessary tools and more:
http://libre.adacore.com/

The Ada France association with many links:
http://www.ada-france.org/

Forums Ada in French :
https://groups.google.com/forum/?fromgroups#!forum/fr.comp.lang.ada/
http://www.developpez.net/forums/f227/autres-langages/autres-langages/ada/

Forums Ada in English :
https://groups.google.com/forum/?fromgroups#!forum/comp.lang.ada/

AdaCore
The company AdaCore offers Ada support on many different hardware and software platforms.

If you plan to use "Ada for Automation" with the Hilscher cifX cards to create real-time solutions, know that the drivers for the cifX cards are available for Windows ® RTX ® or InTime (R ) and for VxWorks ®, and of course Linux platforms.

Your application will therefore run in the environment of your choice.

AdaCore University
AdaCore University is e-learning site devoted to Ada and associated techniques:
http://university.adacore.com/

Adalog
The company Adalog offers too its training services for Ada.

The Wikibook "Méthodes de génie logiciel avec Ada" de Monsieur Jean-Pierre Rosen (Adalog) :
http://fr.wikibooks.org/wiki/M%C3%A9thodes_de_g%C3%A9nie_logiciel_avec_Ada

The Wikibook "Ada Programming":
http://en.wikibooks.org/wiki/Ada_Programming

The Wikibook "Ada Style Guide", a wealth of information on what to or not to do in great edifying explanations:
http://en.wikibooks.org/wiki/Ada_Style_Guide

The reference manual for Ada 2005:
http://www.adaic.org/resources/add_content/standards/05rm/html/RM-TTL.html

The "Rationale for Ada 2005" is also a good source of information:
http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-TTL.html

Your application is not a so-called security application, no more nor less than if you were using a traditional controller.

Unless you use a safety PLC, which is designed for this function, safety is ensured by additional elements such as sensors and security mechanisms, such mechanical stops, or equipment such as a holding tank, a secure enclosure, etc …

Your application can monitor your system and report abnormal conditions by alarms or cut a main contactor, these actions must be doubled according to standardized rules.

The concept of real time is very important in automation as in many other areas.

There are several definitions of what real time is and we will not risk to give another one.

Basically, if the control values you have elaborated in your program arrive outside a specified period of time, they are less useful … your truck is in the wall or soup overflowed.

Do we always need a real-time operating system? It depends on the applications. We distinguish applications that require soft real-time and those that require hard real time.

Number of applications can be satisfied with a soft real time.

If one pilot valves, pumps, regulators or autonomous drives, equipment with high time constants, the soft real-time given by general operating systems today can amply suffice.

Of course, for the axis control where fast and synchronous reaction times are required, a hard real-time operating system is necessary.

As always, engineering job is to properly analyze the problem and design a process control architecture adapted to it.

Technical constraints are rarely preponderant over those strategic or economic.

It’s always nice to find peers who discuss topics that concern us, and we strongly advise you to register on the dedicated forum:
http://slo-ist.fr/forum/index.php

Then, answers to questions benefit all.

Before you embark on this extraordinary adventure of developing your application in a high level language, you might profitably follow the course of the AdaCore University. You will learn the basics of the Ada language, tool use and incidentally be working language of Shakespeare.

The Daniel Feneuille tutorial also allow you to familiarize yourself with Ada, see French tutorial.

Equipped and experienced, you will then have to obtain "Ada for Automation" and libmodbus.

About libmodbus, on Linux it is normally already available in your packets, and if this is not the case, the tools are and the user manuals as well.

The following article should help you get it if you are under Microsoft Windows ®:
A4A : compilation de libmodbus avec GNAT GPS sous Windows

Finally, choose from the sample applications provided by identifying the one that is closest to the application you want to develop.

"Ada for Automation" is a framework for design automation applications in Ada. This framework is intended to allow you to create your own applications easily.

It therefore provides some examples applications, firstly possibly serve as a starting point for your and the other to illustrate the use of this application framework.

The examples are not meant to cover all of the functionality but to provide representative applications of it while remaining simple to access.

Thus, the application App1 implements only the Modbus TCP protocol for communication with both the inputs and outputs of the system and as well with the monitoring tool used to demonstrate, the product PcVue ® from Arc Informatique.

This sample application 1 is a good choice for beginners. You only need your machine to learn and test.

Why PcVue ®? Because in life you have to make choices … You are free to make another one. It is a tool that allows us to simply and quickly create a graphical interface for our applications, which is known to many of the PLC programmers, and you can get a demo version from http: //www.arcinfo com / [Arc Informatique].

The author also uses this demo version that has a major disadvantage, be limited to 25 input / outputs variables, which in practice is reached quickly. Also, it is necessary to juggle this limit by creating multiple graphics applications …

We are certain that other tools can also be used. They are legion under Microsoft Windows ® and there are some Linux.

MBLogic is very interesting technically, it works well but it seems stalled:
http://mblogic.sourceforge.net/index.html

It is written in Python / JavaScript. It should be feasible to adapt the principle to Ada Web Server.

The first version of your application is just a click away.

As it is possible to create your application on Linux as on Microsoft Windows ®, so start on the platform that you own and master. Do not cumulate difficulties.

However, we prefer of course free technologies.

"Ada for Automation" processes your application in a main loop that handles inputs and outputs and call user functions you write.

A library of components, a little rickety for now certainly begs to be expanded. Thank you for your contributions.

"Ada for Automation" uses other components to provide extended functionality. Reinventing the wheel, no thank you!

So you have managed to get "Ada for Automation" and you are facing a number of directories.

app1
This is where you will find the files of the example application 1. This application implements a Modbus TCP server and some clients.

app1simu
You will find here the files for the simulation application for the example application 1.

app2
In this one you will find the files for example application 2. It implements a Hilscher PROFIBUS DP Master cifX card and a Modbus TCP server.

app3
Here you will find the files for example application 3. This application implements a Modbus TCP server and Modbus RTU Master.

book
The book "Ada for Automation" is elaborated here. This book is composed in plain text in the Asciidoc format and processed to provide HTML or PDF files.

build
The directory for A4A construction artifacts. Having their own space, they do not contribute to congestion.

doc
The GNAT Pro Studio development environment can generate documentation from source code automatically and is set to move its production in this directory.

exe
Your executables will be placed here.

exp
Some of my experiences … This should probably not be here.

hilscherx
The directory for the Hilscher cifX API binding. You will need it if you would use a Hilscher cifX board that can provide the connectivity you need to manage your equipment on all major fieldbuses Real Time Ethernet or legacy.

src
There beats the heart of "Ada for Automation". Feel free to dive and experiment.

test
The place to place all sorts of tests and experiments or examples.

GNAT Pro Studio allows to arrange the projects in a project tree with inheriting other projects. This will expand the project by adding or substituting source code files. You will please refer to GPRbuild documentation regarding the projects.

A4A/COPYING
The GPL License you should read carefully.

The following projects are common to all CLI or GUI applications.

A4A/lib_cifX32x86.gpr
The user project for the Hilscher cifX Device Driver library.
It is possible that you have to adjust it to suit your installation.
Only required if using a Hilscher cifX card.

A4A/libmodbus.gpr
The user project for the libmodbus library.
It is possible that you have to adjust it to suit your installation.

A4A/shared.gpr
An abstract project, shared by the other ones and containing common elements.

The following projects are for CLI (command line) applications.

A4A/a4a.gpr
This is the main project file.

A4A/app1.gpr
This is the application example 1 project file, it extends the main project "a4a.gpr".
Only the user program differs from the one included in the main project.

A4A/app1simu.gpr
This is the simulation application for application example 1 project file, it extends the main project "a4a.gpr".
This application replaces the task "Main_Task" of the main project by his own "Main_Task" in which was removed the management of Modbus TCP clients.

A4A/app2.gpr
This is the application example 2 project file, it extends the main project "a4a_hilscherx.gpr".
This application replaces the task "Main_Task" of the main project by his own "Main_Task".
The management of Modbus TCP clients has been replaced by management of an Hilscher cifX board.
The user program also differs from that available in the main project.

A4A/a4a_hilscherx.gpr
This one extends the main project by adding the binding to the Hilscher cifX Device Driver API and related examples.

A4A/a4a_exp.gpr
This project extends the main one with some of my experiments which may found a place in the main project. This should probably not be here.

The following figure shows the tree structure of these projects.

Dashed arrows represent relationships "with".

These relationships exist between a project that uses the services of another, those of a library as libmodbus or GtkAda for example.

The solid arrows indicate a project extension. As already mentioned upstream, it means that we add or replace files.

The "a4a.gpr" / "a4a_gui.gpr" case is a bit particular. We probably should have considered the second as an extension of the former. However, this would have further complicated the following schemes and directories to a tenuous benefit.

The following projects are for GUI (Graphic User Interface) applications.

A4A/a4a_gui.gpr
This is the main project file with a graphic user interface.

A4A/app1_gui.gpr
This project file of application example 1 extend main project "a4a_gui.gpr".
It is same application "app1" but with a graphical interface.

A4A/app1simu_gui.gpr
This project file of the simulation application for application example 1 extends the main project "a4a_gui.gpr".
It is same application "app1simu" but with a graphical interface.

A4A/app2_gui.gpr
It is the project file of application example 2 with GUI, it extends main project "a4a_gui_hilscherx.gpr".

A4A/a4a_gui_hilscherx.gpr
This one extends the main project by adding the GUI and the binding to the Hilscher cifX Device Driver API and related examples.

The diagram below shows the general architecture of "Ada for Automation".

It wants to be self-explanatory. Chapter Design is supposed to provide a detailed explanation.

A console application is defined as default

Of course, it is entirely possible to create an application with a graphical interface, for example with GtkAda, or an application with web interface with Ada Web Server (AWS).

It’s so possible that it is already available for the GUI and on the "roadmap" for AWS. ;-)

The packages allow you to organize Ada code by grouping elements of the application, data types, data, functions and procedures, objects, tasks, other packages, etc … in a logical hierarchy .

The children packages inherit from the parent package, things defined therein are visible to them without the need to mention a "with" clause. Thus, all children packages of "A4A" see what is defined in it and can be used without restriction.

A clause "with" defines a package dependency where it appears to the subject of the clause.

We can represent these package dependencies in a diagram, which could be done later. :-)

We discussed in Chapter Concepts the concept of task, a task representing an instruction execution thread. Several tasks may be executed concurrently, the processor working on the instructions and the data of each task according to a schedule managed by the operating system and, in the case of Ada, by the runtime.

In Ada, it’s easy to create a task, the concept is available in the language.

When designing a multi-threaded application, a recurring problem is the sharing of data and the corollary, the integrity of the shared data or consistency.

This problem is simple to solve in Ada as one can for example define a protected type that encapsulates the critical data and allows concurrent access through functions and procedures which interlock.

An example of use of a protected type is given by the scan on Modbus TCP with "Dual Port Memory", a component that allows the reading by several entities while simultaneously writing is possible only by single entity and locks the reading as writing.

In principle, the tasks in "Ada for Automation" have an interface of a protected type allowing control of the task (Quit, Run, Watchdog) and the recovery of his status.

Related tasks monitor a sign of mutual life, it is the watchdog.

So, your application is comprised of tasks, two predefined, the main task and periodic task, some ancillary tasks, and those you could add according to your needs.

For each Modbus TCP server, one client task is used which will be created automatically by the "Main_Task" task from the supplied configuration. Thus, if a server is slow or unresponsive, scanning of others is always assured optimally.

Each client task runs periodically, the period being defined by the parameter "Task_Period_MS" in the configuration of the task.

Each command has a multiplier, the "Period_Multiple" parameter, which thus defines the period of this command ("Task_Period_MS" x "Period_Multiple") and an offset, defined by the "Shift" parameter, which allows differentiating in time several orders maturing so that the server is not saturated.

The "Dual Port Memory" is actually a protected object that encapsulates an array of registers for input and one for output. The task "Main_Task" manages the update of memory areas Input / Output from the DPM, I / O areas to which the user program has access.

The data types used in the Modbus protocol are registers (or 16-bits word) and booleans (coils and status bits). The protocol defines two data models, wherein the one-bits data and registers data are disjoint, and the other where there is overlap. We prefer the first model and has been defined areas for registers and areas for booleans, respectively registers DPM and booleans DPM.

The diagram is so incomplete as there is an identical construction for booleans not shown.

In terms of configuration, it is performed in package "A4A.Application.MBTCP_Clients_Config" like hereafter for the example application "App1":

Modbus specification defines a data model that contains four tables consisting of bits for inputs (Discrete Inputs) read-only and outputs / flags (Coils) read / write, or registers, 16-bit words, for analog inputs (Input registers) read only and the internal registers (Holding registers) read / write.

Each table has 65536 items.

There are two possibilities, one is that the four tables are disjoint, the other where they are overlaying.
The implementation in "Ada for Automation" is the first type.

The Modbus TCP server is managed by a dedicated task that responds to client requests regardless of tasks dealing with automation.

A locking mechanism is used to manage data consistency blocking readings during the execution of a write operation.

The architecture looks more or less to the one organized for clients. There we find the DPM and the corresponding IO memory areas.

The task "Main_Task" manages the update of memory areas Input / Output from the DPM, but also copies the I / O data in the data server to allow visualization of the raw data.

The design is substantially identical to that of "Modbus TCP IO Scanning".

Configuration is the same and differs only in the parameters of the serial port used by the master and the bus address of the slave in the command table.

On a Modbus bus there can be only one master. The master cyclically polls the slaves as configured in the table.

Instead of having a client task by server as in the case Modbus TCP, one single task performs the function master.

Configuration is performed in package "A4A.Application.MBRTU_Master_Config" like this for the example application "App3" :

This is similar to the Modbus TCP client configuration except the serial port settings and the slave address added in commands.

The following diagram shows the flow of data in the application example 1, detailed in Chapter devoted.

The memory areas are defined in package "A4A.Memory." The "Dual Port Memory" is automatically allocated in package "A4A.Kernel" according to the necessary size.

The black flows at the initiative of Modbus TCP clients.

Flows in green correspond to the scan of inputs and outputs on Modbus TCP servers.

In red are represented the flows managed by the task "Main_Task" of package "A4A.Kernel."

Finally, the blue flows are organized by the user in the functions of the package "A4A.User_Functions" "Map_Inputs, Map_HMI_Inputs, Map_Outputs, Map_HMI_Outputs" called in the main procedure "Main_Cyclic", itself called by the task "Main_Task ".

In the case of the application example 2, "app2" aptly named, just replace in this scheme Modbus TCP clients by Hilscher cifX board.

The DPM of the board also includes a process image with an input area and an output area.

In the scheme of application example 3, "app3", simply replace the Modbus TCP clients by master Modbus RTU.

This interface defines the interactions between the framework and the user program.

The framework calls the functions of the user program defined in package "A4A.Application" as already seen in the paragraphs on tasks "Main_Task" and "Periodic 1".

We have already seen the procedures "Main_Cyclic" and "Periodic_Run_1."

The procedure "Cold_Start" is also called by the task "Main_Task" before entering the cyclical execution loop when initializing the task is completed, so that the user program can make itself some initialization.

An example of use is provided by the "App2" application.

The procedure "Closing" is itself called by the task "Main_Task" when the application is terminated, by the signal "Ctrl + C" in the case of the console application or the "Quit" button in the GUI application before the task closes the communication means.

The "App2" application again provides an example.

User programs can generate an exception such as division by 0. This exception is normally managed and a flag "Program_Fault" then stood up.

The "Program_Fault" function allows the framework to determine the status of this flag and this has the same effect as the "Stop" button.

Except for the fact that there is no other way to restart than to restart the application.

Here below the functional specifications of this application.

Here is a diagram showing the architecture:

After the functional specifications, what the system should do, we can specify how it can do it.

So we brought all the information, sensors and actuators in the control box and all this was wired on a remote inputs / outputs module, Modbus TCP server.

As mentioned a little further upstream:

GNAT Pro Studio allows to arrange the projects in a project tree with inheriting other projects. This will expand the project by adding or substituting source code files. You will please refer to GPRbuild documentation regarding the projects.

This is the application example 1 project file, it extends the main project "a4a.gpr". Only the user program differs from the one included in the main project.

So each file listed in the sources folder, "app1/src", and bears the same name as the one that exists in the sources of the main project, in the "src" folder, replaces or hides the main project file.

While a file existing only in the "app1/src" folder extends the main project.

In what follows, we strive to show what determines the logic of this app1 application.

The process image of inputs and outputs is defined in package "A4A.Memory" in the "src" directory.

If the size is not enough, change it accordingly to the needs.

A detailed description of this scan is available in Chapter Design.

The configuration takes place in the file "a4a-application-mbtcp_clients_config.ads" in folder "app1/src".

For each Modbus TCP server, we use a task that will be created automatically from the configuration entered here.

So for each Modbus TCP server or I / O module, create a configuration and insert it in configurations table "MBTCP_Clients_Configuration".

There! It is done.

The following configuration declares two servers on the same PC, the one of the simulation and the one of the application app1 itself. As the latter loopback is used only for testing purposes, it is disabled.

Note also that only commands 1-3 are useful in this application, the others are there for demonstration and testing.

In the kitchens of "Ada for Automation", Modbus TCP client tasks are created.

They communicate with the rest of the system through an emulation of dual port memory that helps ensure data consistency.

Data is exchanged with the image of the inputs and outputs, so two boolean and two registers arrays.

The curious can go see the package "A4A.Kernel" in the "src" folder.

This configuration takes place in the file "a4a-application-mbtcp_server_config.ads" in folder "app1/src".

We instantiate the generic package "A4A.MBTCP_Server" by providing the desired quantities of items and assign a configuration.

The corresponding memory areas were of course defined, cf. above the package "A4A.Memory".

So the inputs and outputs are connected to the process image of the inputs and outputs.

With a conventional controller, you would define a variable table to play with your sensors and actuators during the synchronization phase for example.

Such a concept does not exist for the moment in "Ada for Automation". This is not very serious, you can use the Modbus TCP server that has the I / O data. You will just have to create either synoptics of your equipment or a simple table …

You also have the GNAT Pro Studio debugger (GDB).

The next step is the definition of objects in your application.

In this example application, this is achieved in package "A4A.User_Objects".

This is by no means an obligation and you can structure your application as you see fit.

So the following code declares inputs, outputs, internal variables, object instances.

It is altogether equivalent to what you would do in a PLC program without input screens.

Nothing more than text files, some readers have already left?

There must be matching your input and output objects with the process image.

This is done on your initiative in user functions you organize as you think.

Such as:

The main loop in "A4A.Kernel" calls the procedure "Main_Cyclic" from package "A4A.Application".

This is fairly standard in automation, agree on.

There we find the procedures defined above: "Map_Inputs" and "Map_Outputs".

These procedures without parameters and without parentheses are very similar to subroutines.

Will easily admit that the code presented above reads as easily as "Structured Text".

The main loop that handles everything, cf. "task body Main_Task" in "A4A.Kernel.Main" is presented below in simplified version to illustrate how everything revolves.

Of course you can modify it to your liking, like the rest of the code of this project, but it is not absolutely necessary and you can probably create many applications with this code.

You can find in it:

Communication needs are extremely diverse and Hilscher has created a range of products covering the needs of the hardware developer, of the automation engineer, of the computer programmer at the OEM, of the integrator or assembler.

So we find solutions for the embedded world to enable electronic equipments such as drives, encoders, measuring instruments, operator panels, etc … to communicate using proven components.

In the PC world, Hilscher offers a range of boards in all formats. These boards are used for test and measurement benches or advanced automation solutions with integrated PLC complying with IEC 61131-3 or even IEC 61499.

The gateway range allows integration of various devices, from a revamping process or of particular interest for the application, in a network architecture using a protocol unsupported by those devices.

Finally, the activity "standard products" is completed in a high proportion of OEM (Original Equipment Manufacturer).

To configure protocol stacks, Hilscher has developed SYCON.net, a tool based on FDT / DTM technology.

This software allows to configure all the products in the range built around the netX.

A lighter tool was developed, the netX Configuration Tool for configuring in a simple way the products in slave version, configuration of slave protocol stacks being significantly reduced compared to master versions.

For PC cards, cifX, Hilscher has developed drivers for several operating systems of the market.

These drivers are based on a ToolKit in C, whose source code is provided, which allows to port the driver to an operating system not supported by Hilscher.

Regardless of the hardware platform, the chosen operating system or protocol used, the interface is common. Your application has a maximum connectivity with minimal porting work.

There is an emulation of this driver for embedded development, allowing to begin the development on a PC-based equipment, enjoying the comfort of this platform, and port without much effort the project on the embedded equipment.

Above these generic drivers, specific drivers have been developed for the major software PLC of the market.

Ada defines a number of basic types and provides the means to create own data types. This is not the subject of this book.

In the parent package A4A, can be found some defined basic types and functions that the control engineer can use in all of children packages without having to specify "with" or "use" clauses.

In automation as industrial computing, we spend time gathering Boolean information in bytes or words, 16, 32 or 64 bits because it is easier to process or vice versa easier to transport, and of course the opposite.

In Ada, it is possible to create a structure containing Boolean information according to a well defined representation with what is called the representation clause, and converting it into the ad hoc container with the unverified conversions functions that it took derive from the suitable generic package.

That’s good, and used in many occasions in "Ada for Automation", but the author does not know whether it is effective to deal with such structures when the data is used in multiple Boolean equations, and it sounds complex for the automation that he remains.

"Ada for Automation" therefore provides the following conversion procedures:

The measure acquired, temperature, pressure, speed, etc. is provided in digital form, mostly an integer, a number of points representing the extent of the measure, which must be scaled, to get for example, a normalized value in the range [-100%, 100 %] or [0, 100%] or a scaled value in engineering units [-30, + 100 °C], [0, 50 Bars], [-10, 300 km/h] …

The timers are objects, we must first instantiate before using them.

Components are objects that inherit from the class "Device", and that we must first instantiate before using them.