[Embedlets-dev] FW: Embedlets Architecture: Dynamic Configs and Persistence...

[Christopher S. <cs...@oo...>]

Here is a post of a background discussion that Andrzej and I had that I
think has general interest: (Andrzej's response to follow)

Andrzej,

The typical scenario is:

1. A new system is installed with new similar but significantly different
hardware, more inputs, valves, etc compared to the last 25 systems.
2. There is a flowchart or written specification of the process defining the
inputs, computations comparisons, logical operations and outputs.

3. The Embedlets required to implement the spec are pre-installed on the
target system, available to the Container.

4. The system is wired using a graphical tool or the XML configuration on
the Workstation.

5. The configuration is downloaded as an XML stream to the target.

6. The Container instantiates the required Embedlets and wires them together
based on the configuration.

7. Modifications to individual Embedlet settings (calibration, scale
factors, limit thresholds, time delays) are adjusted on the running system
similar to adjusting potentiometers on analog systems.

8. The finalized configuration and the adjustments are stored in the targets
flash ROM for immediate recall as well as on the workstation for backup and
versioning.

9. Any variations in the system or alternate configuration settings are done
in real time and likewise saved.

Notice that the code is compiled/linked/installed only once and is used on
all systems whose requirements are within the constraints of the available
Embedlets. This reduces the number of binary packages that need to be
generated, QA'ed and tracked. In my experience this is a very typical
scenario in facilities management, industrial controls, aerospace and home
automation.

Constrained systems might be deployed with workstation generated 'hard
wired' configuration, but they will still need some query capability and
quite likely the ability to update one or more Embedlet parameters.

I have found that the instantiation, serialization/deserialization,
local/remote persistence and property queries/updates can all be handled by
the same interface and a compact piece of implementation code at the
Component/Embedlet level. Please review the Persistence package of OPC for
details.

To respond to your suggestion that JMX and JMS be used as management and
communication protocols: I agree completely. I would not however think that
this would be a part of our mission statement. If we have defined a simple
XML payload with Socket based communication, this can be easily packaged
within a JMS, SOAP... envelope for transport to distributed Enterprise
systems.

I look forward to your document release and feedback on OPC applicability.

P.S. I am in Thousand Oaks, CA (PST)
805-276-0598

-----Original Message-----
From: Andrzej Jan Taramina [mailto:an...@ch...]
Sent: Sunday, February 02, 2003 10:17 AM
To: cs...@oo...
Subject: RE: Embedlets Architecture: Dynamic Configs and Persistence...


Chris:

> A very thoughtful, thorough and well presented document - think that it is
> ready for open discussion.

Thanks...I might tweak it a touch based on your comments, and it should go
out later today or tomorrow sometime.

> I am 90% in agreement with your spec and am struck by the very close
> parallel with the work that I have done so far. This is very encouraging!

Excellent.  I hope it's a case of "great minds thinking alike" rather than
"fools
seldom differ" ;-)

> I have put a little more emphasis on the dynamic configuration primarily
> because that was a requirement for the types of applications that I was
> working on. In the Ajile chips this is achieved by using the static
> 'forName' registration of classes in an available pool then instanciating
> then on demand via an XML configuration. This works pretty well in
> situations where you need to have flexibility within the contraints of the
> type of system deployed.
>
> For example: A system controlling X outputs via Y inputs (lighting
> control) where X and Y can vary. Here the number of Embedlet classes would
> be known and limited but the number of instances and their cross wiring
> can change often. It would be desirable to have the same deployed package
> handle hardware and functionality scaling without having to resort to a
> full deployment cycle.

Are you envisioning a situation where the new config information would be
sent over a connection (say XML over HTTP) to the embedded device, which
would then re-config itself for the new lighting situation?

If so, the architecture I am thinking of would allow for that.  Even though
the
initial config would be "hardcoded" in a generated java class (possibly as a
static singleton instance of the class), the methods to change the config or
build a new one would be still present.  Then all you would need is a
ConfigManager Embedlet that would get the new info (over a connection),
create the new config object, and would ask the Container to restart the
Lighting Embedlet, at which time it could read the new config and keep
running.  Maybe not right off the bat though.....need to get a prototype
running
first with static builds I think.

> Persistence is also an issue in these types of systems because you do not
> want to have to reload your lighting configuration remotely every time you
> have a power restart. The system should be able to automatically store and
> load a configuration locally. Other systems such as manufacturing controls
> may need to have several or even hundreds of configurations available to
> an operator without involving a remote (perhaps not available) system.

Many of these devices don't have external storage, so for a power cycle, you
would have to put the code/configs in flash.  That would solve the issue for
many embedded applications.

My gut feel tells me that the best way to tackle this type of approach (for
a first
cut) is to create a ConfigEmbedlet that handles multiple configs and can be
triggered externally (switch settings, TCP/IP, serial, etc) to restart the
application Embedlet (Lighting in the example).  This makes the container
lighter in weight for the more limited environments, and let's us get some
experience with this type of app before including the functionality as a
more
formal (though probably optional) Container Service.

My vision here is based on the use of the event model for most
command/control and service access functions.  All the ConfigEmbedlet would
need to do is produce a RestartEmbedlet event and send it to the container
to
effect a reconfig (it's a bit more complicated than that, but this is the
key
concept).

By allowing such things, the Container's services can be extended by adding
Embedlets that provide "services" in response to specific event types.  If
they
become common needs, then they can be wired more tightly into the container
implementations.

> Fortunately as you pointed out the solution to these can be easily
> incorporated. In OopScope there is a 'Persistent' interface which actually
> handles both issues and provides remote query capability - an issue in any
> size system.

Maybe the answer (initially) is to create a Container with the right API's
and
events that will support the creation of a Persistence Embedlet that can
provide these services to other Embedlets?  That sounds very attractive to
me,
since it keeps the actual Container footprint very small.

The whole thing revolves around a "fuzzy definition" of what a service is
and
how to add new ones.  Synchronous services (that require method calls)
would probably have to be part of the container.  But event initiated
services
(asynchronous) could be part of the Container, or just Embedlets themselves.

Does all this rambling make sense?  Is it a viable way to handle the Dynamic
Reconfig and Persistence issues, at least initially?

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com