PLC PAC operating system

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

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


Re: PLC PAC operating system
On Tue, 26 May 2009 14:32:09 -0700 (PDT), antaresanto

Quoted text here. Click to load it

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


Re: PLC PAC operating system

Quoted text here. Click to load it

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 snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: PLC PAC operating system

Quoted text here. Click to load it

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.


Re: PLC PAC operating system
On Sat, 30 May 2009 19:27:10 GMT, snipped-for-privacy@yahoo.com (42Bastian

Quoted text here. Click to load it

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


Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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


Re: PLC PAC operating system

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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 snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: PLC PAC operating system

Quoted text here. Click to load it

Reference.


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


Re: PLC PAC operating system
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: PLC PAC operating system
On Tue, 2 Jun 2009 08:22:52 -0600, "Not Really Me"


Quoted text here. Click to load it


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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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 snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: PLC PAC operating system

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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 snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: PLC PAC operating system

Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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.


Re: PLC PAC operating system

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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 snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: PLC PAC operating system
Quoted text here. Click to load it
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.

Quoted text here. Click to load it
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

Re: PLC PAC operating system
On Tue, 26 May 2009 14:32:09 -0700 (PDT), antaresanto

Quoted text here. Click to load it

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


Re: PLC PAC operating system
Quoted text here. Click to load it

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

Re: PLC PAC operating system
antaresanto escribió:
Quoted text here. Click to load it

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.

Re: PLC PAC operating system
Quoted text here. Click to load it

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 .

Re: PLC PAC operating system
On Wed, 27 May 2009 01:55:08 -0700 (PDT), antaresanto

Quoted text here. Click to load it

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 ?

Quoted text here. Click to load it

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

Paul


Re: PLC PAC operating system
Quoted text here. Click to load it

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


Re: PLC PAC operating system
antaresanto escribió:
Quoted text here. Click to load it

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.

Site Timeline