PLC PAC operating system

Does anybody know what's the operating system running on Siemens S7 PLC or other PAC ( programmable automation controllers ) by Siemens ? And what about other companies like Rockwell automation , GE Fanuc, ... Have you got otherwise a link to a survey of the most used operating systems in embedded automation controllers ? thanks

Reply to
antaresanto
Loading thread data ...

Why would you need something that could be called "operating system" on a simple PLC ? Once the control program is executed, it restarts immediately or after the next clock interrupt.

More complex systems supporting multiple loops at different cycle times might even need an operating system.

In the 1970's and 80's it was more or less standard practice that each company had their own realtime dispatcher (or OS if you like). Writing the RT kernel is simple, however, the cost of maintaining it, especially if frequent ports to different hardware platforms are required, will make the in-house kernels less attractive. This is why commercial RT kernel vendors have been so successful recently.

Paul

Reply to
Paul Keinanen

A simple programmable logic controller simply

- reads the inputs,

- executes the control program and

- writes the outputs and then

- restarts. You really do not need an OS for this.

Of course, some means are required to load the control program. Once MS-DOS was a popular alternative to load the program from a floppy, but these days any boot loader is capable of loading from flash.

Paul

Reply to
Paul Keinanen

Dear all , I mean an operating system because PAC ( and some PLC models ) have to handle Ethernet protocols, complex serial protocols, complex applications, some models also executes applications originally written in C. These models are called usually PAC. Some models are really industrial embedded PC. Does anybody know a link to PAC operating systems overview ? I know well that for reading inputs, elaborate and writing outputs you don't need operating system. regards

Reply to
antaresanto

In our firm we made a PLC, functionally equivalent to an S5, in the late eighties. Up to 3 cycles, serial communications, multi-processor, etc. It had a proprietary, simple kernel, made by ourselves, in assembler. Nowadays there are firms like ISaGRAF (I think that's now the name of the product, not the company) that sell libraries from which you can build a PLC. If you look at the portings they provide, that could give you an idea.

Reply to
Ignacio G.T.

I'm not asking about IEC lanaguages environment and runtimes , like ISagraf or others. I'm strictly speaking about the underlying operating system. So what's the oeprating system under Siemens S7 or Rockwell PACs or other .

Reply to
antaresanto

Ethernet protocols or complex serial protocols can be easily implemented with an Interrupt Service Routine (ISR), as long as you have a static storage for the message and a single byte for the state machine state variable. Why would you need an OS for this ?

Is this some Siemens specific naming convention, since I have never heard it before ?

Paul

Reply to
Paul Keinanen

that's not the answer I need. I need info about operating systems on PLCs and PACs. Is there anyone who knows it ?

Reply to
antaresanto

This is not a Support Department. This is Usenet. If you are not ready to share your thoughts and questions in a friendly manner, and be a little less rude, I suggest contacting with Siemens and be prepared to drop some amount of money. The pointer I gave you a couple of posts "above" should have give you a hint, but I suspect you didn't bother to follow it.

Reply to
Ignacio G.T.

What makes you think a PLC is simple ? At the moment you have to be used in a safety related environment, there is no such word as "simple".

And I am pretty sure, they use some kind of RTOS inside.

But unforunately (to me and the company I work for) the PLC guys stick to there in-house RTOSes.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

Maybe you're confusing simple/complex with easy/difficult?

Dealing with safety-critical contexts isn't easy, but it often encourages simplicity.

If you need to use formal proofs of correctness, those are a lot easier for a simple system than a complex one.

Reply to
Nobody

Any PLC safety critical control program should be SIMPLE in order to be easily checked for correctness.

If I had to design a safety critical system, I would avoid any complexity as much as possible, this means getting rid of any RTOS.

What is the problem with in-house RTOSes ? In the early 1980's, every company I worked for had their own RTOS for 8 bit processors.

The real problem with in-house RTOS systems is that someone should maintain it year after year. This is not a very glorious task and finding a competent person to maintain the system is very hard, since any competent person would quit quickly move to more demanding jobs. The problems with in-house RTOS maintenance is the major reason why many companies use commercial RTOSes.

I would prefer to use even a mediocre in-house RTOS with sources rather than using a highly acclaimed commercial RTOS without sources.

Paul

Reply to
Paul Keinanen

I am biased but I think using an already certified RTOS helps a great deal designing a safefy-PLC esp. if you mix it with non-safety related parts like a TCP/IP stack.

But, of course, if the design paradigm says no external software, I'd not write my own RTOS for a PLC because of the complexity. But then, I wouldn't use TCP/IP either.

That's the point. I would wish more project managers would have this view :-)

Though we deliver with sources, I do not understand the whole "only with sources" arguments. Esp. in safety related systems, where you buy a _certified_ RTOS, what are the sources for ? You're not allowed to change a single bit if you do not want to loose certification for this.

If you buy an MCU, you take it as black-box. You apply some tests. That's it. I never heard, peoble asking for the RTL sources for the chips they use.

Again, don't get me wrong. Delivering with sources makes _my_ live a lot easier, but customers live ? I am not sure ...

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

Reference.

If you want to do directed testing, you need the source code to identify the boundary cases.

Reply to
Nobody

Certified is a very tricky word. In general you can not get software components, e.g., an RTOS, certified. There are exceptions of course. Certifiable is a term more often used with software components.

For PLC's the standard in play is IEC-61508, which does allow some component certifications, but only in limited contexts. uC/OS-II, Nucleus, VxWorks, Integrity, SafeRTOS all have been certified as components to IEC-61508 by one or the other of the TUV groups.

The context limitation is that the cert is only valid on the same processor with the same compiler and sometimes with other hardware limitations. Change anything and you have to go through the process again. If you can use the same target, then the sources for the component are not necessary, just a copy of the certification letter must be provided.

Regardless of whether it uses certified or certifiable software components, the final product still must get certified. So there is always more testing and documentation to be done. Any mention of "easy" has to be taken in that context.

In the case of "Certifiable" that we deal with, the concept is to do 90% of the work once and then be able to provide small customizations to achieve certification on a new target. Again, not easy, but easier.

--
Scott
Validated Software
 Click to see the full signature
Reply to
Not Really Me

Sorry ?! Asking for a reference where _no_ source is needed ?

Our customers do _not_ have to test the boundaries of the RTOS functionality. That's why it is certified. Anyway even if they want to, the boundaries are clearly marked in the manual and the safety manual.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

I think you mix things up, uC/OS-II and SafeRTOS are "certifiable". So the user has to do the work of the certification. Though he gets all the needed information and paper by either your company or Wittenstein.

Integrity (and also SCIOPTA) are certified. That is, you get a software component ( as you would buy a safety-PLC) which you can add to your system without the need to certify and test _that_ component again.

Sure. But this is true for every safety related component for a system unless its behavior stays the same.

The same is true for "certifiable" components. But e.g. switching the compiler would also mean a re-certification of the customer-code.

E.g. the advantage we have is, that the kernel is C/C++ compiler independent as long as the assembly-syntax does not change.

Sure. But again. It's adding a safety-PLC to your machine-controller. You have to test your code running on this PLC for correct behavior. But you do _not_ have to prove the correct behavior of the PLC given you obey the limitiation of usage given by the safety-manual.

But it has to be done by the customer. A certified product moves the pain of all this to the RTOS provider.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

Not all PLCs are simple. I have worked on PLCs with psos, VxWorks, Linux and in-house OSes. Since the 80's, they have added a few features beyond simply running a control loop. There are usually a bunch of different fieldbus protocols to support, beyond the IP link to the operator stations. There are redundant PLCs, where two PLCs mirror each other, with a backup unit being ready to take over if the master unit fails. Beyond the control loops, there are background tasks to be performed: download and parsing of new control programs, logging of data, etc - good tasks for an OS.

Also, with a commercial RTOS you will get a TCP/IP stack, file systems and debug tools that the in-house kernel cannot offer. While a kernel might be simple to write, keeping all the drivers updated is not. Writing a utility that displays the status of threads, queues and semaphores could also take a while...

Hans

Reply to
Hans Odeberg

Needed for what? This isn't really my field, but do customers generally only care about certification, or also about whether it actually works? Are the certifications adequate for all customers, or might there be cases where customers need to perform their own validation?

You misunderstand what I mean by "boundary cases".

There are two common types of testing: black-box testing and directed (aka clear-box or white-box) testing. With the latter, you choose test cases in order to force specific code paths to be executed. E.g. if a particular routine stores data in 1024-byte buffers, you might choose test cases with

1023, 1024 and 1025 bytes of data, in order to catch potential fencepost errors.

In order to choose appropriate test cases for directed testing, you have to see the code.

Reply to
Nobody

Right, but this is no boundary test. A white-box test is nothing the customer of a certified component has to do. This is true for a chip, a resistor or a software component.

All you have to test is that you use the component within the "boundaries" given by the spec (manual, safety-manual).

So even no blackbox test is needed as this has also been done by the manufacturer.

Even if you have the code (which our customers have), I am pretty sure they can not run white-box tests. For certain complex OS function we have about 40 white-box tests and you'll need a deep understanding of a) the assembly language and b) of the internal structures of an RTOS.

That's the difference between a certifiable and a certified RTOS. For the latter there is no need for testing.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.