PLC PAC operating system

On Sat, 30 May 2009 19:27:10 +0000, 42Bastian Schick wrote:

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

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.

On Sat, 30 May 2009 19:27:10 GMT, bastian42@yahoo.com (42Bastian
Schick) wrote:

>On Wed, 27 May 2009 02:38:53 +0300, Paul Keinanen <keinanen@sci.fi>
>wrote:
>
>>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.
>
>What makes you think a PLC is simple ? 

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


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

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.

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

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

On Sun, 31 May 2009 21:13:29 +0300, Paul Keinanen <keinanen@sci.fi>
wrote:

>>And I am pretty sure, they use some kind of RTOS inside.
>
>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.

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.

>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

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

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

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 :-)
Use <same-name>@monlynx.de instead !

On Sun, 31 May 2009 19:52:43 +0000, 42Bastian Schick wrote:

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

Reference.

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

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

Nobody wrote:
> On Sun, 31 May 2009 19:52:43 +0000, 42Bastian Schick wrote:
>
>> 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 ?
>
> Reference.
>
>> 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.
>
> If you want to do directed testing, you need the source code to
> identify the boundary cases.

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
Lafayette, CO

On Tue, 02 Jun 2009 14:11:52 +0100, Nobody <nobody@nowhere.com> wrote:

>On Sun, 31 May 2009 19:52:43 +0000, 42Bastian Schick wrote:
>
>> 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 ?
>
>Reference.

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

>
>> 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.
>
>If you want to do directed testing, you need the source code to identify
>the boundary cases.

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 :-)
Use <same-name>@monlynx.de instead !

On Tue, 2 Jun 2009 08:22:52 -0600, "Not Really Me"
<scott@validatedQWERTYsoftware.XYZZY.com> wrote:


>>> If you buy an MCU, you take it as black-box. You apply some tests.
>>
>> If you want to do directed testing, you need the source code to
>> identify the boundary cases.
>
>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.

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.

>The context limitation is that the cert is only valid on the same processor 
>with the same compiler and sometimes with other hardware limitations. 

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

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

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.

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

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.

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

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 :-)
Use <same-name>@monlynx.de instead !

On 27 Maj, 01:38, Paul Keinanen <keina...@sci.fi> wrote:
> On Tue, 26 May 2009 14:32:09 -0700 (PDT), antaresanto
>
> <antaresa...@yahoo.it> wrote:
> >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
>
> 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.
>
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.

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

On Tue, 02 Jun 2009 17:56:51 +0000, 42Bastian Schick wrote:

>>> 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 ?
>>
>>Reference.
> 
> Sorry ?! Asking for a reference where _no_ source is needed ?

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?

>>> If you buy an MCU, you take it as black-box. You apply some tests.
>>
>>If you want to do directed testing, you need the source code to identify
>>the boundary cases.
> 
> 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.

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.

On Wed, 03 Jun 2009 19:58:58 +0100, Nobody <nobody@nowhere.com> wrote:

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

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.

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

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 :-)
Use <same-name>@monlynx.de instead !