The PRMC Interface
Under construction! Please contribute to this interface definition!
Introduction and Motivation
The objective is to define an
open flexible universal
software and data interface
between process modelling software
and industrial (or laboratory) automation
systems fullfilling the following demands:
- The interface is simple enough to be understood and used by people
with limited programming skills and small resources
(i.e. it is not a 2nd
CAPE-OPEN).
-
The interface supports exchangeable process models.
- The interface supports
the collection and storage of process data
independently from a specific process model.
-
The interface allows the programming of general purpose software tools
(e.g. for sensitivity analysis or parameter fitting)
independent of a specifc process.
-
The interface introduces a minimum of overheads and is compatible to
UNIX and Windows IT environments.
- The input-, output- and parameter-definitions for a specific process
are freely accessible.
Process independent part
The interface definitions will be published here and they should
be useable for all process models:
- Headers and declarations for different programming languages (C,C++,FORTRAN,...).
- Automatic source code generation of the process specific parts.
- ASCII based data formats editable by EXCEL type tools (.csv).
What do you require/expect?
Process specific part
The
process specific definitions are proposed to consist of only 3 files:
- the static process parameters pk definition
(see Excel and
ASCII/CSV templates).
- the dynamic process inputs xi(t) definition
(see Excel and
ASCII/CSV templates).
- the dynamic process outputs yj(t) definition
(see Excel and
ASCII/CSV templates).
For examples please refer to the individual
processes (e.g. the
EAF).
Remarks
The
process model end user of a process model
should have the free choice to use any of the
general purpose interfaces provided here (in the future).
The primary interface programming language was choosen to be
C
(ISO/IEC 9899:1999)
with the restriction to use only features not hindering the procurement
of interfaces to other programming languages. It is therefore
"call by reference".
By providing wrapper routines, the end-users and developers
are free to use other programming languages.
CLI/.GNU support may follow on demand.
The process model developer has to provide only one library routine (source, compiled, ...).
This routine is called from the different user interfaces.