Using Ada (or SPARK) in Ada-unaware environment

Using Ada (or SPARK) in Ada-unaware environment

[Maciej Sobczak]

Hi,

Imagine a control system (to be developed) which needs to interact with 
some devices. Those devices are supplied with C drivers and libraries.

What is the recommended practice for developing this control system in 
Ada (or SPARK)? I basically see two options for this:

1. Enjoy Ada's ability to interface with C libraries (pragma Import) and 
write everything in Ada.

2. Write separate programs in C (or C++) that will be responsible only 
for talking to the devices via their C access libraries. Write the main 
controller in Ada, as another separate program, and use some form of 
interprocess communication to have all those components talk.

The advantage of the second option is that the controller part can be 
easily tested in isolation or in a fake environment.

Are there some other options for this? What is the industry recommented 
practice?

Regards,

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Using Ada (or SPARK) in Ada-unaware environment

[Niklas Holsti]

Maciej Sobczak wrote:
> Hi,
> 
> Imagine a control system (to be developed) which needs to interact with 
> some devices. Those devices are supplied with C drivers and libraries.

Been there a couple of times.

> What is the recommended practice for developing this control system in 
> Ada (or SPARK)? I basically see two options for this:
> 
> 1. Enjoy Ada's ability to interface with C libraries (pragma Import) and 
> write everything in Ada.

I have always used this option. It works well *unless* the C 
libraries try to interact with the OS/kernel using signals or 
timers (sleeps), or create their own threads.

Sometimes the C library interface (C header files) relies heavily 
on #define macros, which can make writing the Ada specs rather 
boring. It helps to put one layer of application-specific C 
routines between the C libraries and the Ada code, presenting a 
simpler, application-specific C-Ada interface.

> 2. Write separate programs in C (or C++) that will be responsible only 
> for talking to the devices via their C access libraries. Write the main 
> controller in Ada, as another separate program, and use some form of 
> interprocess communication to have all those components talk.

I would do that only if the C libraries use the OS features I 
mentioned above, in which case it would be easier to isolate the C 
code in its own process (= program). Still, you would need an Ada 
run-time (tasking) that connects well to the interprocess 
communication primitives, eg. lets an Ada task wait on an OS mutex 
or signal.

> The advantage of the second option is that the controller part can be 
> easily tested in isolation or in a fake environment.

Hmmm... I have usually done that in option 1 by implementing a 
test/fake version of the C libraries themselves. The only reason 
why this could be simpler in option 2 is if the test/fake code 
must be written in C and needs to use the OS features mentioned 
above. In option 1, the test/fake code can be written in Ada and 
use Ada tasking and I/O if necessary, which seems a lot simpler to me.

My 2 cents...

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Using Ada (or SPARK) in Ada-unaware environment

[Peter Amey]

Maciej Sobczak wrote:
> Hi,
> 
> Imagine a control system (to be developed) which needs to interact with 
> some devices. Those devices are supplied with C drivers and libraries.
> 
> What is the recommended practice for developing this control system in 
> Ada (or SPARK)? I basically see two options for this:
> 
[snip]

I think I would probably go for a third option!  Use Ada's ability to 
interface to other languages to write an Ada boundary layer that 
interfaces to the C device drivers and provides a better and more 
abstract interface upwards to the rest of the program.  Then write the 
main control program using the new, Ada interfaces.

This mixed approach retains the beenfits of your option 1 by maximising 
the amount of Ada.  It also maintains the advantages of your option 2 
because it is still possible to test in a synthetic environment by 
providing stubs for the Ada interface layer.

Finally, it gives a degree of portability and maintainability because a 
chnage of low level device can be accommodated by rewriting the Ada 
boundary layer rather than the core application.

regards

Peter

Re: Using Ada (or SPARK) in Ada-unaware environment

[Jeffrey R. Carter]

Peter Amey wrote:

> I think I would probably go for a third option!  Use Ada's ability to 
> interface to other languages to write an Ada boundary layer that 
> interfaces to the C device drivers and provides a better and more 
> abstract interface upwards to the rest of the program.  Then write the 
> main control program using the new, Ada interfaces.

This is similar to the approach that I would take, but I would create a 
low-level interface to the C, which is reusable by multiple applications, and 
layer on top of that an application-specific interface.

-- 
Jeff Carter
"This school was here before you came,
and it'll be here before you go."
Horse Feathers
48

Re: Using Ada (or SPARK) in Ada-unaware environment

[tmoran]

Interfaces generally should be as small and conceptually simple
as possible, whether they are for levels of device control or
language-change interfaces.  So, it seems to me, the OP should
decide on a structure first, then decide which modules should be
in Ada or C.

Re: Using Ada (or SPARK) in Ada-unaware environment

[Steve]

"Maciej Sobczak" <no.spam@no.spam.com> wrote in message 
news:dqnkoj$pb4$1@sunnews.cern.ch...
> Hi,
>
> Imagine a control system (to be developed) which needs to interact with 
> some devices. Those devices are supplied with C drivers and libraries.
>
> What is the recommended practice for developing this control system in Ada 
> (or SPARK)? I basically see two options for this:
>
> 1. Enjoy Ada's ability to interface with C libraries (pragma Import) and 
> write everything in Ada.
>
> 2. Write separate programs in C (or C++) that will be responsible only for 
> talking to the devices via their C access libraries. Write the main 
> controller in Ada, as another separate program, and use some form of 
> interprocess communication to have all those components talk.
>
> The advantage of the second option is that the controller part can be 
> easily tested in isolation or in a fake environment.

Please explain why it is easier to test the the control part in isolation or 
in a
fake environment in C than in Ada.
This is not obvious to me.
In my experience, I have found just the opposite to be true.  I have found 
that
it is easier (in the long run) to do as much code as possible in Ada.

BTW: Tools are available to assist in creating Ada interfaces to C 
libraries.

Steve
(The Duck)

> Are there some other options for this? What is the industry recommented 
> practice?
>
> Regards,
>
> -- 
> Maciej Sobczak : http://www.msobczak.com/
> Programming    : http://www.msobczak.com/prog/ 

Re: Using Ada (or SPARK) in Ada-unaware environment

[Maciej Sobczak]

Steve wrote:

>>2. Write separate programs in C (or C++) that will be responsible only for 
>>talking to the devices via their C access libraries. Write the main 
>>controller in Ada, as another separate program, and use some form of 
>>interprocess communication to have all those components talk.
>>
>>The advantage of the second option is that the controller part can be 
>>easily tested in isolation or in a fake environment.
> 
> Please explain why it is easier to test the the control part in isolation or 
> in a
> fake environment in C than in Ada.
> This is not obvious to me.

I wrote that the control part would be written in Ada, not in C. The 
"isolation" means that the control part would not be in any way 
dependent on the device-related libraries or interfaces, so that it 
could be possible to just take the control program to some other machine 
(where the devices are not available) and run it there with fake stubs, 
without the need to recompile nor relink anything.

> BTW: Tools are available to assist in creating Ada interfaces to C 
> libraries.

The controller is not likely to need everything that the driver library 
provides, which means that it makes sense to wrap the whole thing into 
something that exposes simpler and safer abstractions - those which are 
actually needed. This means that automated conversion of C interfaces to 
Ada interfaces might not be optimal.

This wrapper for the device library can be either a module or a separate 
program. Separate program makes sense, because can be accessed also by 
other controllers, which do not even need to be written in Ada (think 
about scripting tools).

This total breaking of the system into independent processes can allow 
me to easily exchange parts, test them in separation and reuse in 
different environments (including script tools) - that's why I would 
lean toward this solution, but I wanted to know your opinions on the 
subject.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Using Ada (or SPARK) in Ada-unaware environment

[Simon Wright]

Maciej Sobczak <no.spam@no.spam.com> writes:

> This wrapper for the device library can be either a module or a
> separate program. Separate program makes sense, because can be
> accessed also by other controllers, which do not even need to be
> written in Ada (think about scripting tools).

I don't see why you need separate *programs* to achieve this. My
experience is with a shared library (Unix) setup:

basic.so <----+--------------------- Ada program
              |
              +---- tclbinding.so -- Tcl program

but thinking back the underlying architecture was a shared-memory
scheme and basic.so provided the interface to that. Clearly
_something_ has to be shared!

Re: Using Ada (or SPARK) in Ada-unaware environment

[John]

I have a suggestion that might serve your control system that you
propose to implement in Ada.  The suggestion builds on your option #1
to import interfaces from C and to write device controls in Ada.

I have an experience that suggests you might divide that scheme into
two levels of abstraction.  Write "thin" bindings to the hardware
vendors' C libraries and capture these into a class of object whose
interface encapsulates the capabilities of the hardware.  Let me call
this class "controller".  For example, there might be a controller
that implements a particular brand of motor and lets its user move
clockwise or counterclockwise at some speed, for a specific number of
revolutions.

Write another layer of abstraction (in Ada) that presents an interface
to the control system.  Let me call this class "device".  An example
might be an actuator device that moves a cart to some position, or a
mirror to some angle.  The device's specification represents the needs
of the control system.

Implement the device's actions by invocations of the controller.

Consider the benefits of this scheme:
- Vendor's C library is completely encapsulated;
- A device can be "upgraded" by replacing the controller with a new
model, and the control system is unaffected;
- Data that characterize the hardware is separated from the data that
the control system presents to its user.
- Composite devices can be built.   For example two-axis motions built
of two separate controllers;

Here are a couple references to reports of a very large control system
that uses this strategy:

Fong et al., "Application Software Structures Enable NIF Operations,"
ICALEPCS 2001.
Lagin et al., "The Overview of the National Ignition Facility
Distributed Computer Control System", ICALEPCS 2001.
Both are at:
http://accelconf.web.cern.ch/accelconf/ica01/proceedings

Carey et al. "The National Ignition Facility: Early Operational
Experience
with a Large Ada Control System" in SigAda 2002.