> As promised on several occasions in the past, here is the first draft
> of what could possibly become a EU funded free software project in
> "control". Comments are very welcome, but please don't send private
> emails: use the mailinglists :-)
>
ok - at the risk of making a fool of my selfe - my comments are to the list ;)
hofrat
>
> --------------------------------------------------
>
> ==================================================================
>
> Orocos-II: Open contROl COmponentS: Infrastructure for Integration
>
> ==================================================================
>
> Orocos-II is a candidate "FP6 Integrated Project" with the following
> mission statement:
>
> "Design, implementation and integration of free software
> embedded infrastructure and software components to support
> the development and deployment of real-time and large-scale
> distributed feedback control systems."
>
>
> Explication of the various terms in this mission statement:
>
> - "Design, implementation and integration"
> The project has three levels of deliverables (for its software aspects):
> - Design: conceptual design, software patterns. These are application
> and implementation independent. The emphasis is on reuse of
> patterns at the various control levels.
> - Implementation: of the conceptual designs, with emphasis on
> reusability and quality of code.
> - Integration: (i) to make maximal use of existing FLOSS efforts;
FLOSS ??
> (ii) to maximally interface with (open) industrial standards.
>
> - "Free software"
> - contractually agreed Free Software results: LGPL license for
> libraries, GPL for applications, and relevant license for parts
> that are done together with existing FLOSS projects.
what happens to non-lib/non-app i.e. kernel-modules,code-generator output (GPL ?)
> - maximal reuse of existing FLOSS software: Linux, Gnome/KDE,
> RTAI/RTLinux/Ecos, Comedi, Coin3D/OpenCascade, ACE/TAO, CORBA Orbs, ...
> - pro-active clustering with other FLOSS projects:
> - integration: provide professional design support that can help
> promising existing projects to integrate and grow.
> - re-factoring of existing software, for improved software
> engineering quality.
> - application support: approach system integrators and application
> builders as a de facto "consortium" to do business with.
>
> - "Embedded"
> - focus on those parts of the control problem that
> run in the work floor machine controllers, not
> - focus on those design department's desktop functionality that
> support the above-mentioned embedded software.
>
> - "Infrastructure"
> - not applications in the first place, but everything needed to build
> applications
toolchains/Linux-control-distribution ?
> - pre-competitive: majority of industrial users can use it as a base
> for their own products. Cf the status of the operating system and
> the internet, but now targeted to control applications.
don't get the second sentence ?
> - middleware (interfaces and components, CORBA)
> - basic components in various control application domains.
> - platform independence.
for low end archs like SH4 I belive platform independance could be very hard
to achive - platform independance easaly ends up requiring inacceptably strong
platforms - I wonder if platform independance is such a key issue for some
parts (i.e. kernel modules)
> - bridges to existing protocols and standards (CIP, IEC...., field
> busses, ...)
>
> - "Software components"
> - modularize complex software systems according to the principles of
> software components (Szierpinski): lowest level are objects,
> offering method call interfaces in class libraries; around them,
> "service" components are built, that can operate as stand-alone agents
> in a distributed system
> - in practice: use the CORBA and Java approach, because these are
> platform-independent. CORBA has an extra advantage, in that it is
> also language independent, and much more independent from a single
> vendor.
I belive that corba/java will exclude a large number of industrial target platforms as it will be too heavy waighted...
> - .NET is not a priority option because of its "lock in" to one
> single vendor. Except maybe if there is enough demand to build
> Mono components (Mono is a FLOSS implementation of part of the
> .NET infrastructure).
>
> - "Support development and deployment"
> - big emphasis on software patterns:
> - software patterns have proven their value as a way to optimize
> the representation and the discussion about software designs:
> they provide standardized terminology and procedures to describe
> designs that have proven their validity in extended practice.
> - conceptual level documentation to spread "best practices" in
> easy to grasp way
> - implementations on which concrete applications can be built by
> "plugging in" functionality with well-defined interfaces.
> - provide efficient, platform and language independent
> implementations, where possible.
> - interact with other projects, in order to maximize portability and
> modularity (= let development take place where best critical mass
> is available)
> - applications built in the project are "tools": programming,
> visualisation, simulation, distribution, configuration,
> validation, etc.
what I belive is missing, as in many projects, is a systematic path for
technology transfere - what I mean is that such a complex conceptual
approach would need to include something like tutorials/seminars or what
ever technology migration path one preferes to get the entire framwork
into industrial R&D .
>
> - "Real-time, large-scale, distributed"
> Industrial control applications can roughly be divided in three levels
> of "control":
>
> (1) Machine.
> Bandwidth: high.
> Latency: low. (Hard real-time.)
> Time horizon: short.
> Centralization: high.
>
> (2) Workcell.
> Bandwidth: medium.
> Latency: medium.
> Time horizon: medium.
> Centralization: medium.
>
> (3) Factory.
> Bandwidth: low.
> Latency: high.
> Time horizon: long.
> Centralization: low.
>
> These three levels require different implementations and support; but
> the feedback control concepts are very similar. So, the project tries
> to use the same software patterns (= conceptual models) in order to
> reduce the complexity to understand the whole software system.
> In addition, all the "overhead" software (configuration, packaging in
> components, user interfacing, etc.) is almost completely reusable.
>
> - "Feedback control systems"
> These are software-driven systems in which the actions and behaviour
> of the system is adapted on-line based on the measurements that are
> done on the system. Typically, a feedback control system has two
> "inputs":
> - "feedforward", coming from models of the system, and steering the
> system to the desired state under the conditions that the system
> behaves as modelled.
> - "feedback", which changes the system's behaviour based on on-line
> measurements that detect how and where the system deviates from its
> model.
> So, adaptability through feedback is the technological key of the
> functional software components, and the project provides the support
> and the tools to program and execute such adapative systems.
>
> ====================================================================
> Motivation
>
> Research aspects:
> - discovery and description of relevant software patterns.
> - high-quality implementation design, with an eye on: efficiency,
> portability, application-independence, decoupling.
decoupling what ?
>
> Application aspects:
> - to find the most appropriate interfaces:
> - places to "cut" the system in modules.
> - definition of the API with which these modules interact.
new API ? no attempt to use the interface capabilities that POSIX provides and
integrate the interfaces via POSIX coplient API ? what would be the advantage
of a new-home-brew API here - especially with respect to the anticipated
integration of external software projects that might allready exist ....
> - to find the most appropriate FLOSS components to reuse/adapt.
> - to find the appropriate boundary between application-independent
> components and application-dependent components.
>
>
> Economic aspects:
> - competitive advantages:
> - high potential for large-scale and long-lasting impact.
> - community building is much easier and cheaper than for closed
> source software.
> - large scope and application-independence: significantly reduces
> the risk to develop poorly reuseable designs and implementations.
> - can profit maximally from cost-reduction and co-development
> leverage of FLOSS community.
> - to make complex system infrastructure into "commodity", both with
> respect to the _software_ as with respect to the _documentation_.
> - to increase use and service potential of European SME industry:
> making ones own control system is a _very_ large task for small
> companies nowadays, because of the high dependence on single vendors
> in a very "balkanized" market. This project should drastically
> decrese this entry threshold to the control market.
>
>
> ====================================================================
>
> RTD Work plan
>
> WP1 Component support
> CORBA 3.0 interfaces for components developed in other WPs.
>
> The activities in this WP involve straightforward encoding of
> on the basis of well-defined interfaces and functionalities.
> However, this implementation takes significant time.
>
> The activities in the following WPs involve roughly equal efforts in
> design and in implementation. The design effort focuses on patterns
> and functionality; the implementation on reuse of, and integration
> with, other FLOSS projects.
>
> WP2 Modelling and simulation
> Machine: system dynamics, hybrid real-time control, program
> verification + execution.
> Workcell: synchronization over network, capacity and material
> transport simulation.
> Factory: effects of putting orders into the system, defects,
> cancellation of orders, etc.
>
> The emphasis is on structured descriptions of all "control objects".
> This modelling catalogue is central to all other activities.
>
> WP3 Control
> Machine: Real-time control; "reflex" estimation and decision making.
> Workcell: distributed control; "tactical" estimation and decision making.
> Factory: Agent systems; "strategic" estimation and decision making.
>
> The focus is on providing "control kernels", i.e.
> application-independent infrastructure that implements the fundamental
> architecture of feedback control:
> - optimal decoupling of functionality in appropriate components.
> - "correctness by construction"
> - highly structured designs, in order to facilitate analysis,
> verification, monitoring and code generation.
> - automatic reconfigurability, by "migrating components/agents" (=
> make knowledge available where it is needed, without hard
> programming).
> - the "hybrid" aspects of control, at all three levels.
> - distributed systems.
>
> WP4 User interfaces
> The design and implementation of interfaces with the following
> goals:
> - cross-platform, toolkit independent.
> - dynamic, i.e.. adaptable on-line to changes in interface demands
> or changes in "machine" configuration.
> - plotting, graphics, visualisation, signal processing components.
> - support for "on-line" programming by local operator.
> - support for the "control kernel" structures.
>
> WP5 Programming tools
> - support for building CORBA components around available
> functionality.
> - support to fill in application-dependent functionality in the
> application-independent "control kernels".
>
> WP6 Configuration and deployment tools
> - support for the "control kernels".
> - compatibility with relevant network and field bus standards.
> - integration on new relevant hardware and operating systems (RTAI,
> DSP, Ecos, Jaluna, TAO/ACE/CIAO, ...).
If this should make it into industry easy then an integrated something like
a distribution will be needed - just providing a kernel and compatibility with
standards I don't think will do it.
>
with configurability and on-line adaptation/programing and distributed
systems being on the agenda I'm supprised not to find security as a
seperate KEY issue.
>
> Dissemination Work Plan
> (where possible in collaboration with cluster projects!)
> webbook of control, with fully citable and refereed contributions.
> RTOS documentation ...; Project Workshops;
> contribute to information about licensing issues for commercial use
> (in cooperation with clustered projects); development of
> free course material, ...
>
>
> Training Plan
> Project Workshops: include hands-on training.
> ...
>
>
> Management Work Plan
> ...
>
>
> Consortium Agreement:
> - simple "intellectual property" protection policy: every knowledge
> + software contributed is available under the project free
> software licenses, and possible patented technology can be used
> unconditionally in the software.
I'm interested in seeing what trees legal departments will start klimbing with
statements like this ... will be interesting to see what such a license would
realy look like - this sounds like a patent-prevention patent :)
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.