embedlets-developer — Outpost Embedlet container developer list

[Embedlets-developer] Re: Embedlet comments

[Ted K. <tk...@ya...>]

Andrzej,

Most of the issues in this post that deal with the graphical wiring together of
software components I responded to in earlier posts so I guess there is no need
to repeat them here.



> 
> >  The Component market is the 'holy grail'.  The wiring tool
> >  is just a support technology for this market.
> 
> That's what they said about J2EE (and EJBs), and about JavaBeans before 
> that...but it hasn't really materialized.  How would the embedded space be 
> different?

From the research I have done on JavaBeans it appears to me that the two things
that killed its potential for creating a large component market was 1) the lack
of a robust method for long term persistence of object graphs and 2) an event
mechanism that was not general enough to allow an extremely wide range of
software components to be easily wired together.  Number 1 has already been
solved and I think we have an excellent shot at solving number 2.

As for EJBs, it seems to me that doing enterprise Java development right is so
complex that highly skilled Java programmers are absolutely needed in order to
'knit' everything together.  If even the Java developers can not agree on
fundamental things like whether Container Managed Persistence or Bean Managed
Persistence is the best persistence mechanism to use then, to me, this is an
indicator that EJBs are not yet mature enough to support non-programmer
application assemblers.

The Embedlet space is looking like it is significantly simpler than the EJB
space and the more I work on a solution to the elevator problem the more I am
convinced that Embedlets have a real shot of being the first Java software
component technology to create a large and successful component market.



> > So, I propose VPL (Virtual Peripheral Library) as the
> >  official name.  What does everyone think?
> 
> For what pieces of the Outpost/Embedlet puzzle?
> 
> I see device drivers (or virtual peripheral drivers) as just special cases of
> an 
> "embedlet".  One that may need regular polling (or a separate thread of 
> execution where supported), and that would primarily produce Embedlet 
> Events that are lower level/hardware oriented (eg. bit values, streams, etc),
> 
> but might respond to control events as well.
> 
> It may make sense to distinguish "embedlets" which contain application logic,
> 
> from "device drivers" that sit next to the hardware.  But there is some
> overlap, 
> if you use the Event model to glue the two together (with the Event 
> Management provided by the container itself).

Over the past few weeks JAPL has been developed to solve the device drivers
problem.

Here is the simple Embedlet application again:

http://embedlets.sourceforge.net/devdocs/diagrams/embedlets_v.05.jpg

Could you draw up a model of the same application that uses an alternative to
JAPL to solve the device driver problem?



Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] Re: General event mechanism

[Ted K. <tk...@ya...>]

Andrzej,

I read through your event mechanism description and, believe it or not, it is
almost identical to the event mechanism that was developed for JavaOS.  I think
the fact that you independently came up with an event mechanism that is very
close to the event mechanism that the pricipal designer of Apple's PCI device
driver architecture, Sun and IBM arrived at after years of effort is
significant.

Here is the summary that is at the end of the Event System chapter in the
JavaOS book:

"There are several advantages to using an event broker.  Consumers can register
in one place to receive events from all producers of events of that type.  New
producers of the event type can be added at any time, and existing consumers of
the event type will automatically receive events from the new producer.  Event
queuing and dispatch code are centralized, and event delivery can be
prioritized."


As for the event types themselves, we both ended up going with one
EmbedletEventListener interface and multiple event types which inherit from a
single EmbedletEvent class.  The fully qualified names of the event sub-classes
seem to be an elegant way to globally uniquely identify event types.

Where our current approaches differ is 1) direct event registering vs.using an
event broker and  2) having multiple interfaces for registering event listeners
on a event producer vs. having one generic event registration interface for all
producers.


I have read through the JavaOS event chapter multiple times and I have heavily
marked it up.  There are a number of things I really like about the event
broker approach.  The two things I am presently unsure of are whether or not an
event broker still allows software components to be wired together graphically
and whether or not it is too heavyweight an approach for the needs of an
embedded system.  JavaOS is a full blown operating system that requires a lot
of thing to happen dynamically.  I am not sure how dynamic a typical embedded
system needs to be.

I think that some more discussion on this topic and some experimenting would be
sufficient to clarify these two issues for me.

Is there any chance that I could persuade you to obtain a copy of the JavaOS
book (Inside the JavaOS Operating System, Saulpaugh and Mirho, Addison-Wesley,
ISBN 0-201-18393-5, available from Amazon) so that we can discuss the merits of
an event broker approach using a working and proven example as a starting
point?


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] Re: Design Criteria

[Ted K. <tk...@ya...>]

Andrzej,

> > Here are a few design criteria that I was working under as
> > I was exploring the Embedlet event mechanism:
> > 
> > - Must allow pre-compiled and pre-serialized software
> > components (Embedlets) to be graphically wired together
> > using a wiring tool.
> 
> I'm not against this approach, but am very skeptical of the value of
> Graphical 
> Programming/Construction tools.  Java IDE's attempted to do just that, but
> real 
> world problems tend to get complex quite quickly, and graphical tools with 
> code generation never managed to step up to the challenges.


I have had an interest in Graphical Software Component wiring since attending
Mark Davidson's JavaBeans session at JavaOne 2000.  Mark Davidson is the
JavaBeans technical lead at Sun and over the years I have had the opportunity
to ask him what went wrong with the original JavaBeans vision and how this
could be fixed.

He said that one of the primary problems was that when JavaBeans first came out
there was not a good long term persistence mechanism available for it and
without this capability a market for JavaBeans components could not be made. 
JavaStudio and the original BeanBuilder graphically wired together JavaBeans
very well but without being able to persist the object graphs that were created
the approach was doomed.

The early IDE vendors worked around this problem by dynamic code generation but
this is a relatively poor and unreliable way to solve the JavaBeans
configuration and wiring problem. 

The new Long Term Persistence API has solved the persistence problem but after
the initial failure most people seem to have forgotten that JavaBeans were
originally designed as a general purpose software component technology capable
of supporting a large software component market for people that wanted to
graphically wire applications together.  Beyond this, with EJBs and the
enterprise market taking off like it did there were little resources or desire
to pursue the original JavaBeans vision.

Mark and some other people as Sun have been working hard over the years to come
through on JavaBeans's early promise and now they have the new BeanBuilder tool
that demonstrates that the JavaBeans idea as originally envisioned works.  I
think that the opportunity to bring this technology to existing IDEs would be a
tough sell but the Embedded Java space is just now taking off and I think that
this technology could be very successful here.

Here is Mark's Software Component Assembly manifesto:

http://tkosan.javadevices.org/misc/embeddedjava/manifesto.html

The new BeanBuilder tool is open source and I would like to use it as the
foundation for the initial proof-of-concept Embedlet Wiring tool.



> I have a vision of an Embedlet system where the embedlets themselves can 
> include some reasonably complex logic (kind of like servlets in concept).  I 
> don't see these Embedlets being developed using graphical tools, since the 
> logic that can be specified with such soon gets to be more complex and more 
> trouble than just coding it in Java.  

We are in complete agreement here.  The Embedlets themselves will often be very
complex and so they will probably be developed in Java by skilled Java
programmers.  The graphical wiring capabilities are just for allowing
non-programmer application assemblers to assemble applications using standard
software components (Embedlets).



> The Outpost container would provide a number of facilities and component 
> services that the embedlets could use.  Logging, Management, External 
> Communications, Events and such.

I agree that the container could offer standard services but I think that the
services should be pluggable so that if one wanted to put a minimal service
Embedlet Container in a uVM it could be easily done.



> The "glue" where you configure the container, all the device drivers and 
> embedlets (components) and standard services, including how they all 
> interact, dependencies and such, would be done using an XML config file, 
> again similar to how servlets and EJB's work these days, and how their 
> respective containers are config'ed (Tomcat, JBoss, WebLogic, etc.)

I think that we will need to discuss this point further.  I think that if a
non-programmer application assembler is developing an Embedlet based
application then they should be able to do so by directly wiring the
application together using a graphic wiring tool (which is a technique that has
been proven to work well by JavaStudio and the various versions of the
BeanBuilder).

But I agree with you in that I do not want to *force* people to only use a
graphic wiring tool to develop Embedlet applications.  For experienced Java
programmers I think that your deployment via an XML configuration file is an
excellent idea that has also been proven to work well in a number of
situations.

I do not see why we can not provide both mechanisms especially since they seem
to be complementary.



> This XML config is likely to not be as simple as James might want, simply 
> because configuration is rather complex as are the applications that users 
> might want to create built on the Outpost framework.  Though it should be 
> simpler than something like Tomcat or JBoss's XML config.

So far the experience I have had with developing a solution to the elevator
problem indicates that quite complex applications can be assembled by
graphically configuring components and wiring them together.  I hope to have my
solution available for critiquing within 2 weeks so that we can see if I am
missing something critical.



> For more capable processors (eg. PC's with a JVM) the container could 
> dynamically read the config at startup and use dynamic proxies and other 
> techniques to instantiate the "application.  On less capable processors,
> there 
> would have to be a "code generator" that would read the XML config and then 
> generate the "glue" code statically, which would then be compiled into a
> self-
> contained Outpost application (container and components) that could actually 
> run on the embedded device.  

The route that the wiring tool is taking is to allow the application to be
graphically wired together and then the application's complete object graph is
saved using the LTP API and then also deserialized into the embedded system.  I
have already successfully deserialized small applications into a TINI as a
proof of concept (it worked well) and I think that this technique will work
with the uVM too.



>Basically, there would not be a single Outpost 
> Container implementation.  Outpost would be a collection of specs, interfaces
> 
> and utility classes that would have differing implementations for platforms
> of 
> differing capability.  Though the embedlet/device driver code should be 
> common, the deployment of the final application would be different.  It's the
> 
> only way I see to be able to address the wide spectrum of target processor 
> capabilities (uVM to TINI to JStamp to PC, etc.). 

I think that we should definitively prove that one Embedlet specification is
incapable of spanning the full spectrum of target environments before falling
back on multiple specifications.  I currently think that one specification will
be sufficient.



> At some point, if someone wants to build a graphical UI that will generate
> the 
> XML config files, that's fine and dandy.  But I don't think it should drive
> the 
> architecture of the container, since that will place artificial limits on the
> 
> container that will likely translate into roadblocks to usage of Outpost in
> the 
> real world.  
>

I think that, just like with security, if the graphical wiring capability is
not built in from day one that it can not be successfully be tacked on
afterwards.  In order to accommodate graphic wiring, Embedlets simply need to
permit their properties to be configured using setters and getters (achieved
mostly through naming conventions) and they need to allow for the registering,
unregistering and handling of events.  They should suffer no more than normal
JavaBeans have by being able to be using in a graphic wiring tool.



> I thought our goal was to make the integration of outlying devices (some
> quite 
> intelligent with some serious capability, eg. JStamps) with the back office 
> Enterprise systems (J2EE/.NET/etc) much easier, and especially to get the 
> server-side/corporate Java developers more comfortable with embedded 
> development.  

With JAPL, Embedlets can handle all possible 'peripherals' from simple devices
to the most complex backend system.  Again, this is shown in the following
simple Embedlet application (notice that it is hooked up to a backend
enterprise system):

http://embedlets.sourceforge.net/devdocs/diagrams/embedlets_v.05.jpg

My primary goal is not to get enterprise developers more comfortable with
embedded development.  My goal is to allow the semi-technical IT personnel
which are present in most companies to be able to graphically wire together
Embedded systems and attach them to backend enterprise systems with minimal
help from the the enterprise developers.

My thought was that the $25/hour IT personnel should not have to bother the
$100/hour enterprise personnel more often than was absolutely necessary in
order to attach the eventually large number of embedded systems that companies
will eventually need to be hooking to their enterprise systems.

In my scheme, the enterprise developers are primarily used as a 'back door'
method for marketing the Outpost idea to companies.  Even though some of them
might catch the embedded systems bug, I think that most of them will not have
the necessary background for interfacing embedded systems to their company's
processes.

Without graphic wiring capabilities Embedlets are not usable by my pet target
user base.



> > - Can not use dynamic event proxies.
> 
> Sure!  Why not?  The Outpost specs should be independent of whether the 
> implementation of an Outpost-compliant container can support dynamic 
> proxies or not (see comments above on how that might work).  

I spent a significant amount of time digging into the dynamic proxy API and it
will only run on JDK 1.3 and up APIs.  Numerous classes in the API were
enhanced to accommodate dynamic proxies (like the serialization API) and almost
no embedded Java system are going to have these capabilities in the near
future.

The good news is that the main reason that dynamic proxies are needed is
because of all the listener types that Java's event mechanism uses like
ActionListeners, WindowListeners, etc, etc,.  So far my research has indicated
that Embedlets will work fine with just *one* event listener:

public interface EventReceiver //All Embedlets implement this interface.
{
   receiveEmbedletEvent(EmbedletEvent ee);
}

Since all Embedlets that need to receive events implement one interface there
is no need for dynamic event proxies.  Simply have an Embedlet register itself
as an event listener for a specific type of EmbedletEvent on any given target
Embedlet and thats it.  It is so simple that it will easily fit even on uVM.



Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] Re: VBB and PLC's

[Ted K. <tk...@ya...>]

James and Andrzej,

> Regarding PLC's:
> 
> > It might be a good place for embedlets to cut their teeth
> 
> I'm nervous about this.  PLC's are even more limited than PIC's.  I think 
> embedlets should consider such limited devices but that the place to cut the 
> teeth is on TStik/JStamp type controllers first.

I think that there is an elegant synthesis here.  Embedlets are software
components that are suppose to encapsulate platform independent *embedded
logic* and we should not care how this logic is generated.


When one considers what tools can be used to develop the logic that is present
inside of Embedlets, the following possibilities immediately present
themselves:

Embedlet logic can be developed using:

1)  Java.  Highly skilled Java programmers can use Java to develop Embedlet
logic.  An example of this would be the ElevatorSystemController and
ElevatorFloorController Embedlets.  These should be developed by expert
programmers with an intimate understanding of the problem domain.  Since these
are highly engineered components they will cost much to develop but then they
can be sold to anyone who is building elevators.

2)  PICBASIC.  For people who are not skilled Java developers there is no
reason why a PICBASIC interpreter Embedlet could not be created and then people
who know how to program in PICBASIC can easily develop their own Embedlet
logic.  If Embedlets are capable of being graphically wired together using a
wiring tool then these people will not even necessarily be aware that they are
using Java at all.

3)  LADDER LOGIC.  If Embedlet logic can be developed in PICBASIC why not allow
it to also be graphically developed using LADDER LOGIC?

4)  ANY TOOL THAT PEOPLE WANT TO USE...


The deeper that I dig into developing a solution to the Elevator challenge the
more I am convinced that Embedlets are capable of elegantly accommodating an
extremely diverse set of needs.


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

RE: [Embedlets-developer] RE: PLC help (plcopen.org)

[Ted K. <tk...@ya...>]

James,

> A) Try not to be overwhelmed by all the depth of the
> material out there - it
> is easy to feel a sense of 'information overload' with
> all of this
> B) Try to be aware but not intimidated by these
> 'kinda-like' techniques (I
> call these techniques rather than technologies) to make
> sure embedlets is
> the 'base class' of all these things

When I start to feel the pressures of 'information
overload' with respect to Embedlets I remind myself that
any group attempting to develop an Embedlet-like technology
is faced with the same difficulties.  This makes me feel
better ;-)

As for the 'base class' idea, I think that it will turn out
to be a key concept and it was one of the ideas that the
Embedlet work we did back on the JStamp list also pointed
to as being important.



> BTW - How is the Elevator Challenge going. It was a very
> tough one to hand
> out first up - thats why I chose it.. It is sometimes
> quite challenging to
> push from idea to implementation and all the issues
> without silver bullets
> that 'spring up' can be quite discouraging. I am keen to
> see your final
> solution.

It is going very well and it has turned out to be an
excellent application for discovering workable solutions
for a tentative Embedlet design.

I have ended up scrapping a significant number of 'good'
ideas over the past 3 weeks that would not work but the
ideas that are left seem to be pretty solid.

I do not know if anyone has noticed but all of the Embedlet
related design documents that I have been developing while
attempting to come up with a solution to the elevator
problem are present in the CVS (so far there have been 15
commits).

All the design documents are in OpenOffice 1.0's XML file
formats so they can be managed by a CVS system very easily.


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

RE: [Embedlets-developer] Re: Embedlet comments

[James C. <ca...@vi...>]

>However, many components and even more funcational
>embedlets (with application logic in them) will need to be built using
classic
>Java development techniques first. Bit of a chicken and egg scenario there.


Unfortunately, the chicken and egg scenario is a SERIOUS issue for this
whole project.

'Build it and I am sure they will come'

But who the hell is going to build the biggest most generic resuable freely
available embedded resource on the planet!! For nothing!

That is the real issue here. Without weaving some commercial sense into this
in some way (ie without rejecting commercial interests immediately without
thought) then this challenge just keeps getting bigger.

JC


> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Monday, January 27, 2003 9:20 AM
> To: emb...@li...
> Subject: [Embedlets-developer] Re: Embedlet comments
>
>
>  From Ted:
>
> > It is my opinion that if we are able to bring a
> >  simple,  platform-independent, snap together component
> >  market to the embedded space that it will be a huge
> >  success.
>
> I agree with you, but to be successful you need lots of pre-built
> components
> first.  That requires standard interfaces/contracts and a
> Container specification
> (and some implementations for common platforms, PC/JStamp/uVM/etc) first.
>
> If you do the design of the Container and component contracts
> well, with a
> solid XML configuration vocabulary, then layering a sexy
> graphical UI on top of
> that is pretty easy.  However, many components and even more funcational
> embedlets (with application logic in them) will need to be built
> using classic
> Java development techniques first. Bit of a chicken and egg
> scenario there.
>
> Designing a container and the contracts it needs (eg. interfaces,
> lifecycles,
> etc.) that will eventually support this vision is a non-trivial
> task, especially since
> it needs a lot of flexibility to handle the wide range of
> platform capabilities and
> constraints that we are targeting.
>
> >  I do not personally have any problems with the XMLDOM route
> >  but my primary goal is a huge market of Embedded Components
> >  that can be graphically wired together by a 'Component
> >  Assembler' class of application developer.
>
> I believe that the design of the Outpost container/component
> architecture will
> be the critical piece of the technology puzzle here, with a
> graphical UI being
> some nice sex/sizzle for later.
>
> Many people have tried to float graphical assembly tools....but
> for the most
> part they have not succeeded (JavaBeans are a good example of
> this).  Most
> real-world problems require custom logic....which is where the graphical
> assemblers break down.  And trying to create a graphical programming
> language is probably not going to succeed in the short term.
> Look at how all
> the current containers work....all XML-based config files....nary
> a graphical
> assembly tool anywhere to be seen, though these might start to
> appear as the
> configs stabilize, container best practices solidify and the
> configs get complex
> enough to warrant such tools
>
> As for DOM....it won't ever fly on an embedded platform.  Too much memory
> overhead in instantiating the XML parse tree.  On embedded
> platforms, event
> based (SAX) XML parsing makes much more sense.  For the construction
> tool, that builds the glue that binds the container/components
> from the XML
> config, almost any XML parser can be used, since that process
> would likely be
> done on a more capable box (like a PC).
>
> > Yes, flowchart based programming has been around for years,
> >  but the killer idea here is that the Embedlet standard can
> >  allow a *huge* market for platform-independent, reusable,
> >  pre-serialized embedded components to be created.  The new
> >  XML based long term persistence format makes this feasible
> >  now.
>
> I'm not convinced that a JavaBeans approach with serialized instances is
> really that valuable.  It hasn't succeeded in the more classic
> Java space.  What
> seems to have garnered favour and market share is writing code to a
> container spec (eg. servlets, embedlets, EJBs) and specifying the
> "instances"
> that need to be created in an XML config file instead.
>
> The argument for a huge market for serialized components never
> materialized
> in the Java world....so I am quite skeptical that it will do so
> (at least in the
> shorter term) in the embedded world.  More likely that an
> Embedlet Container
> approach that is reminiscent of Servlet (and other) containers would gain
> traction and usage a lot faster.
>
> >  The Component market is the 'holy grail'.  The wiring tool
> >  is just a support technology for this market.
>
> That's what they said about J2EE (and EJBs), and about JavaBeans before
> that...but it hasn't really materialized.  How would the embedded
> space be
> different?
>
> > So, I propose VPL (Virtual Peripheral Library) as the
> >  official name.  What does everyone think?
>
> For what pieces of the Outpost/Embedlet puzzle?
>
> I see device drivers (or virtual peripheral drivers) as just
> special cases of an
> "embedlet".  One that may need regular polling (or a separate thread of
> execution where supported), and that would primarily produce Embedlet
> Events that are lower level/hardware oriented (eg. bit values,
> streams, etc),
> but might respond to control events as well.
>
> It may make sense to distinguish "embedlets" which contain
> application logic,
> from "device drivers" that sit next to the hardware.  But there
> is some overlap,
> if you use the Event model to glue the two together (with the Event
> Management provided by the container itself).
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>

RE: [Embedlets-developer] Lots of posts...

[James C. <ca...@vi...>]

Good to see you back in form Andrzej

1) I totally agree that a XML backend is what we are after. And that any
graphical viewer is just a visualiser for that XML. That is exactly the
approach I have taken in VBB. (Which is a VB front end and Java BackEnd -
openVBB). I would like to keep the XML as simple as we can to begin and grow
it upwards from there but if we can come up with the rich version up front
then I am happy with this also. My issue is that we are collectively don't
have 1000's of man years of knowledge in the fields of its actual
application - as a group we seem better at theory and abstraction than hands
on application. SO the thinking was to keep it simple as possible and move
upwards.

2) I don't agree about the PLC as 'not important' are you kidding? It is
probably the biggest field of embedded engineering out there!? However I
think there has been a little confusion, I am not suggesting PLC's run
embeddlets - actually I am suggesting the other way around, that embedlets
can run PLC code.
Specifically, I want a Ladder Logic ==> Embedlets.xml translator so that
java devices running the embedlets framework can run PLC code. I think this
is enourmously valueable. Furthermore in building this translator I think
there are valueable lessons to be learned about the embedded domain - there
is ALOT* of overlap between PLC's conceptually with embedlets forgetting
that Ladder Logic is a pretty much redundant way of representing executable
code but it is a standard. The fact that openPLC are coming out with an XML
representation is exciting because perhaps the  Ladder Logic ==>
Embedlets.xml is simply an XML transform of the openPLC.xml schema.

3) Yes, I am considering making VBB 'open source' It has alot to offer,
openVBB is pretty much an implementation of the Outpost like Container. It
uses a java backend with most of what we have been talking about with java
objects created by reflection and an event driven SignalProducer/Consumer
wiring model which can handle both synchronous(clocked) and
aysnchronous(change-response) logic operators and has a XML-SVG component
representation to boot.

>Embedlets are supposed to be open source.
4) No the standard and reference implementation will be open source. I think
there will be many commercial implementations of the standard and don't have
a problem with that. Not all TCP/IP stacks are opensource yet they implement
a standard!

James


BTW - This replytoall and then edit out the author to reply to the list is
confusing. Is this what we all decided was the prefered mechanism? I would
prefer reply to go to the list..

> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Monday, January 27, 2003 9:33 AM
> To: emb...@li...
> Subject: [Embedlets-developer] Lots of posts...
>
>
> ...can you tell I've been trying to catch up?  Anyhow...it should
> hopefully spark
> some more design discussion.
>
> I've been doing a lot of investigation in the Avalon framework (I
> think we can
> adopt some of the principles, but in the short term AV5 won't be
> ready soon
> enough for use...we could retrofit later if there was any desire
> to), and also into
> JMX.  Some ideas are starting to gel on how to provide a flexible
> container
> architecture, with optional JMX management features for Outpost.
> But I have
> a bit more work to do, and some prelim design before it'll be ready for
> discussion.
>
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>

[Embedlets-developer] Lots of posts...

[Andrzej J. T. <an...@ch...>]

...can you tell I've been trying to catch up?  Anyhow...it should hopefully spark 
some more design discussion.

I've been doing a lot of investigation in the Avalon framework (I think we can 
adopt some of the principles, but in the short term AV5 won't be ready soon 
enough for use...we could retrofit later if there was any desire to), and also into 
JMX.  Some ideas are starting to gel on how to provide a flexible container 
architecture, with optional JMX management features for Outpost.  But I have 
a bit more work to do, and some prelim design before it'll be ready for 
discussion.


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

[Embedlets-developer] Re: Embedlet comments

[Andrzej J. T. <an...@ch...>]

 From Ted:

> It is my opinion that if we are able to bring a
>  simple,  platform-independent, snap together component
>  market to the embedded space that it will be a huge
>  success.

I agree with you, but to be successful you need lots of pre-built components 
first.  That requires standard interfaces/contracts and a Container specification 
(and some implementations for common platforms, PC/JStamp/uVM/etc) first.

If you do the design of the Container and component contracts well, with a 
solid XML configuration vocabulary, then layering a sexy graphical UI on top of 
that is pretty easy.  However, many components and even more funcational 
embedlets (with application logic in them) will need to be built using classic 
Java development techniques first. Bit of a chicken and egg scenario there.

Designing a container and the contracts it needs (eg. interfaces, lifecycles, 
etc.) that will eventually support this vision is a non-trivial task, especially since 
it needs a lot of flexibility to handle the wide range of platform capabilities and 
constraints that we are targeting.

>  I do not personally have any problems with the XMLDOM route
>  but my primary goal is a huge market of Embedded Components
>  that can be graphically wired together by a 'Component
>  Assembler' class of application developer.  

I believe that the design of the Outpost container/component architecture will 
be the critical piece of the technology puzzle here, with a graphical UI being 
some nice sex/sizzle for later.

Many people have tried to float graphical assembly tools....but for the most 
part they have not succeeded (JavaBeans are a good example of this).  Most 
real-world problems require custom logic....which is where the graphical 
assemblers break down.  And trying to create a graphical programming 
language is probably not going to succeed in the short term.  Look at how all 
the current containers work....all XML-based config files....nary a graphical 
assembly tool anywhere to be seen, though these might start to appear as the 
configs stabilize, container best practices solidify and the configs get complex 
enough to warrant such tools

As for DOM....it won't ever fly on an embedded platform.  Too much memory 
overhead in instantiating the XML parse tree.  On embedded platforms, event 
based (SAX) XML parsing makes much more sense.  For the construction 
tool, that builds the glue that binds the container/components from the XML 
config, almost any XML parser can be used, since that process would likely be 
done on a more capable box (like a PC).

> Yes, flowchart based programming has been around for years,
>  but the killer idea here is that the Embedlet standard can
>  allow a *huge* market for platform-independent, reusable,
>  pre-serialized embedded components to be created.  The new
>  XML based long term persistence format makes this feasible
>  now.

I'm not convinced that a JavaBeans approach with serialized instances is 
really that valuable.  It hasn't succeeded in the more classic Java space.  What 
seems to have garnered favour and market share is writing code to a 
container spec (eg. servlets, embedlets, EJBs) and specifying the "instances" 
that need to be created in an XML config file instead.

The argument for a huge market for serialized components never materialized 
in the Java world....so I am quite skeptical that it will do so (at least in the 
shorter term) in the embedded world.  More likely that an Embedlet Container 
approach that is reminiscent of Servlet (and other) containers would gain 
traction and usage a lot faster.

>  The Component market is the 'holy grail'.  The wiring tool
>  is just a support technology for this market.

That's what they said about J2EE (and EJBs), and about JavaBeans before 
that...but it hasn't really materialized.  How would the embedded space be 
different?

> So, I propose VPL (Virtual Peripheral Library) as the
>  official name.  What does everyone think?

For what pieces of the Outpost/Embedlet puzzle?

I see device drivers (or virtual peripheral drivers) as just special cases of an 
"embedlet".  One that may need regular polling (or a separate thread of 
execution where supported), and that would primarily produce Embedlet 
Events that are lower level/hardware oriented (eg. bit values, streams, etc), 
but might respond to control events as well.

It may make sense to distinguish "embedlets" which contain application logic, 
from "device drivers" that sit next to the hardware.  But there is some overlap, 
if you use the Event model to glue the two together (with the Event 
Management provided by the container itself).

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

[Embedlets-developer] Re: Design Criteria

[Andrzej J. T. <an...@ch...>]

Ted mentioned (in a private email that he said I could respond to on the list):

> Here are a few design criteria that I was working under as
> I was exploring the Embedlet event mechanism:
> 
> - Must allow pre-compiled and pre-serialized software
> components (Embedlets) to be graphically wired together
> using a wiring tool.

I'm not against this approach, but am very skeptical of the value of Graphical 
Programming/Construction tools.  Java IDE's attempted to do just that, but real 
world problems tend to get complex quite quickly, and graphical tools with 
code generation never managed to step up to the challenges.

I have a vision of an Embedlet system where the embedlets themselves can 
include some reasonably complex logic (kind of like servlets in concept).  I 
don't see these Embedlets being developed using graphical tools, since the 
logic that can be specified with such soon gets to be more complex and more 
trouble than just coding it in Java.  Developers would create embedlets using 
normal Java programming tools.  This approach would also apply to the 
creation of device drivers that embedlets could use to control/interface with 
real hardware devices (such as PLC's for instance).

The Outpost container would provide a number of facilities and component 
services that the embedlets could use.  Logging, Management, External 
Communications, Events and such.

The "glue" where you configure the container, all the device drivers and 
embedlets (components) and standard services, including how they all 
interact, dependencies and such, would be done using an XML config file, 
again similar to how servlets and EJB's work these days, and how their 
respective containers are config'ed (Tomcat, JBoss, WebLogic, etc.)

This XML config is likely to not be as simple as James might want, simply 
because configuration is rather complex as are the applications that users 
might want to create built on the Outpost framework.  Though it should be 
simpler than something like Tomcat or JBoss's XML config.

For more capable processors (eg. PC's with a JVM) the container could 
dynamically read the config at startup and use dynamic proxies and other 
techniques to instantiate the "application.  On less capable processors, there 
would have to be a "code generator" that would read the XML config and then 
generate the "glue" code statically, which would then be compiled into a self-
contained Outpost application (container and components) that could actually 
run on the embedded device.  Basically, there would not be a single Outpost 
Container implementation.  Outpost would be a collection of specs, interfaces 
and utility classes that would have differing implementations for platforms of 
differing capability.  Though the embedlet/device driver code should be 
common, the deployment of the final application would be different.  It's the 
only way I see to be able to address the wide spectrum of target processor 
capabilities (uVM to TINI to JStamp to PC, etc.). 

At some point, if someone wants to build a graphical UI that will generate the 
XML config files, that's fine and dandy.  But I don't think it should drive the 
architecture of the container, since that will place artificial limits on the 
container that will likely translate into roadblocks to usage of Outpost in the 
real world.  

I thought our goal was to make the integration of outlying devices (some quite 
intelligent with some serious capability, eg. JStamps) with the back office 
Enterprise systems (J2EE/.NET/etc) much easier, and especially to get the 
server-side/corporate Java developers more comfortable with embedded 
development.  Inventing a Graphical programming paradigm will probably not 
do that (though it might be nice to have of course).....having a good container 
architecture, some core services, that will allow Java programmers to write 
embedded code quickly (eg. by using familiar container concepts as already in 
existance with Servlets et al) will achieve these goals.

> - Must run on systems as small as a TINI (and perhaps even
> a uvm).

Agreed.  But PLC's?  I think those are too limited in their functionality to 
include at this stage. (Note: I'm using the classic definition of a PLC here...not 
that of a generic u-processor.  I don't think anything smaller than a high end 
PIC running uVM should be targetted).

> - Can not use dynamic event proxies.

Sure!  Why not?  The Outpost specs should be independent of whether the 
implementation of an Outpost-compliant container can support dynamic 
proxies or not (see comments above on how that might work).  Some Outpost 
implementations may well be able to support such advanced features (I see 
threading, dynamic classloading and the like as similar features, that if 
available, should be useable, but not mandatory).

James's comments on the "standards" that are evolving in the embedded 
device arena are well taken.  But the bulk of these so-called "standards" are in 
reality just proposals.  A true standard is in wide deployment (eg. TCP/IP is a 
standard, WS-Security is not), and none of these are.  I thought our intention 
was to make Outpost and Embedlets the defacto, open-source standard for 
such things.  The fact that there are similar efforts out there (some of a 
proprietary nature, something I wish to strongly avoid) just validates our 
direction and market opportunity.




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

[Embedlets-developer] Re: General event mechanism

[Andrzej J. T. <an...@ch...>]

Ted discusses the event mechanism:

> I looked through the Embedlet traffic we generated on the
> JStamp list and actually I found a post or two from you
> that talked about a very general Event mechanism.  At that
> time I did not have a good feel for why a general event
> mechanism was superior to a more tailored Event mechanism
> (like what is present in AWT) but after playing with the
> wiring tool mockup for the past couple of weeks I think I
> understand this better now.

> Are these the kind of ideas you were referring to when you
> talked about a 'general event mechanism'?

Not quite.....I don't like the use of a the event type specifier in the Event 
Sender interface (see below), and there is probably no need for that.

The bones of the event management should probably be provided by an 
Outpost Container service.  So if you need to receive events you would 
implement the EventConsumer interface and specify in the XML config file that 
you want to receive events and of what kind (more on that later).  Same thing if 
you want to send events...you implement EventProducer and specify in the 
XML that you will create events and of what type.  Both interfaces will have a 
method that allows you to get a reference to the Container's Event Service, 
which you actuall do calls on.  Something like this (for a listener).

public interface EventConsumer 
{
   public void receive( EmbedletEvent e );
}

Registration of the EventConsumer should be done transparently by the 
Container!  The component lifecycle (create/start/stop/destroy for instance) 
would guarantee that you would not receive any events till after the start() 
method was invoked, ensuring that your component was suitably initialized 
first.  All part of the Container responsibilities.

In the XML config defining an Embedlet that is an EventConsumer, you would 
specify what types of events you wanted to receive.  

That's the easy case, and is almost identical to Ted's example, but let's look 
how an event sender might actually send a new event:

   EmbedletEventService eventService = Outpost.getEventService();

   EmbedletEvent	event = eventService.getEventInstance();

   event.setType( typeSpecifier );

   //  ...do some stuff with the event you want to send.  Set data, etc.
  
   eventService.send( event );

Note that with this approach the EventService could automatically ensure that 
the Embedlet is only sending events of the types specified in the config XML (a 
very useful cross-check).  It also simplifies the Embedlet code, since the 
container handles the routing of events to registered listeners....the Embedlet 
doesn't care nor does it need to know.

What is a bit tricky is how to specify the Event Type in a globally unique way, 
since you don't want a developer to end up with a situation where the event 
types were duplicated by two different embedlets/components, for different 
purposes.  

One way is to use integers as event types, with a single EmbedletEvent class, 
which is handy since it's compact and processing them is quite efficient (rather 
than string compares), and you can use Select/case constructs in a single 
receive() method to distinguish between different events.  But the issue there 
is how to ensure that different event types don't reuse the same integer 
specifier.

One approach that bears investigation is where there is a base class (possibly 
abstract) that is an EmbedletEvent.  Specific types are created as subclasses 
of the base class.  The component's XML config file then would specify which 
fully qualified Event subclasses it either consumed or produced, along with a 
method to be called upon receipt of such an event.  For instance, the XML 
descriptor for an Embedlet that both sends and receives events might look 
like:

<embedlet name=ChaeronGPS" class="com.chaeron.embedlets.GPS" >
   <events>
      <consumes class="com.chaeron.embedlets.events.NMEASentence" 
                          method="receiveNMEASentence" />
      <consumes class="com.chaeron.embedlets.events.GarminPacket" 
                          method="receiveGarminPacket" />
      <produces class="com.chaeron.embedlets.events.GPSEvent" />
   <events>
</embedlet>

This would allow you to create a generic receiver method (that takes a 
EmbedletEvent superclass and then do instanceof() comparisons) or multiple 
methods that each receive a single specific event type (class).  

Either runtime reflection or construction-time code generation could be used to 
provide the glue between the container and the component for the event 
handling, depending on the Outpost implementation being used.

What is interesting is that this approach could work for both threaded and co-
operative models of execution.   We'ld need to design the Embedlet contract in 
such a way that co-operative processing is possible, for those platforms where 
threads are not available.  The container can optionally use threaded 
execution of the components if such is supported.  Otherwise, it basically uses 
the events to schedule execution across multiple components in a serial 
manner.  This means that all Embedlet operations should be conducted via 
events (eg. writing to a back end server should be done by sending an 
appropriate event that will perform the communication).  Events could have a 
priority value so that there would be some way to prioritize their execution as 
well.

> So, here is what the SignalSender/SenderReceiver event idea
> evolved into:
> 
> 
> public interface EventSender
> {
>   add(type of operation)Receiver(EventReceiver er);
>   remove(type of operation)Receiver(EventReceiver er);
>   EventReceiver[] get(type of operation)Receivers(); //get
> the receivers for a specific type.
>   EventReceiver[] getAllReceivers(); //get a list of all
> receivers 
> 
>   set(type of operation)Properties    //Temporal
> properties, etc.
>   get(type of operation)Properties
> }
> 
> public interface EventReceiver //All Embedlets implement
> this interface.
> {
>    receiveEmbedletEvent(EmbedletEvent ee);
> }
> 
> 
> For the Elevator Embedlet the following EventReceiver
> registration methods might be present:
> 
> addFloorReceiver(EmbedletReceiver er); //For receiving
> Floor events like 'SetDirectionLights' and
> 'SetCurrentFloorDisplay'.
> 
> addShaftReceiver(EmbedletReciever er); //For receiving
> Shaft events like 'MoveElevator'.
> 
> 
> 
> The main way that a general event mechanism seems to differ
> from a more specific event mechanism like AWT's is that the
> type of 'Listener' passed into an AWT addXXXListener method
> is Listener type specific while the 'Listener' (Receiver)
> in a more general mechanism uses a single type of listener
> (in this case org.embedlet.EvenReceiver).
> 
> 
> It also appears to me that, in a general event system, the
> type of the Event is used to indicate what to do with the
> event.  For example, if all Embedlet events inherit from
> EmbedletEvent then the Elevator Embedlet can send
> FloorEvents through the general event mechanism to
> controllers that are responsible for running each floor and
> ShaftEvents to the controller's that are responsible for
> running each elevator shaft, etc.
> 
> Different EmbedletEvent types are created to handle all
> event needs.


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

[Embedlets-developer] Re: Rebooting your dishwasher....

[Andrzej J. T. <an...@ch...>]

Ted comments:

> I wonder what a reasonable strategy would be for increasing
> the reliability of a system as complex as the BMW 745? 

Systems that are that complex are running all over the place (the net is a good 
example, aircraft, power stations, medical systems, etc...).  And sometime in 
the future, use Embedlets!  So there is no excuse.

There are many ways to increase the reliability of such complex systems.  
Good architecture.  Loosely-coupled, layered functionality.  Encapsulation.  
Clean interfaces with common transport protocol definitions. Formalized and 
extensive Unit, Integration and System testing.  And the list goes one.

The real issue I see is that the 745 never should have been released with such 
poorly implemented software.  If you are not willing to do all of the above, then 
you should stay away from writing software in mission critical (and very 
possibly life critical) applications.

> I can not imagine how horrible it would be to try to
> trouble shoot one of the more modern automobiles.

If it was architected to best practices, this would not have been very difficult at 
all.  I think BMW underestimated the effort required to produce such software 
and did not invest in the architecture/design (or quality people that do such) of 
the system.  It sounds like it was just "hacked" together, rather than 
"engineered".  Rather ironic given BMW's reputation for engineering. ;-)




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

[Embedlets-developer] Re: VBB and PLC's

[Andrzej J. T. <an...@ch...>]

James:

> a) To use Virtual Breadboard's openVBB framework as the (free) schematic
> editor of the ladder logic diagrams

If we were to use this as a GUI tool for the embedlet container, would you 
release the source code under a suitable open source license?  If there is a 
commercial flavour (say paid extensions) I would oppose any such use.  
Embedlets are supposed to be open source.

What's it written in?  Probably VB or C from the installation specs.  I'm not sure 
that limiting execution to a Windows platform is a good idea, and would 
hesitate to use two different languages in the embedlets project.  

Thanks for the offer though....

Regarding PLC's:

> It might be a good place for embedlets to cut their teeth

I'm nervous about this.  PLC's are even more limited than PIC's.  I think 
embedlets should consider such limited devices but that the place to cut the 
teeth is on TStik/JStamp type controllers first.

> Demonstrate how the embedlet wiring concept can be used to develop
> executable ladder logic diagrams.

I see very little value in this challenge, since there is a good chance that the 
Embedlet container will not be suitable for PLC's.

More on why I think that later today....

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

RE: [Embedlets-developer] RE: PLC help (plcopen.org)

[James C. <ca...@vi...>]

Tead,

I think the point is that there are several 'kinda-like' embedlets things
already out there. The question for us is to

A) Try not to be overwhelmed by all the depth of the material out there - it
is easy to feel a sense of 'information overload' with all of this
B) Try to be aware but not intimidated by these 'kinda-like' techniques (I
call these techniques rather than technologies) to make sure embedlets is
the 'base class' of all these things
C) Try get something like a reference implementation happening, and in
particular see if we can find a REALLY REALLY simple XML representation to
capture the thoughts.
D) Look for anything that resembles transformable components of the
'kinda-like' technique (XML) ie PLC-XML ==> Embedlet Representation XML to
make sure our representation supports it and to learn from it. This is why
these standards are interesting because they are condensed knowledge of
these things.

In essense, I want to create an XML schema representation of the
serialisable form of the Bean Heirachy in its minimal form and ensure as
much as is possible that this form is generic enough to cover these
'kinda-like' techniques.

One of the difficulties with java is that it proposes to look ahead but
genericness is actually quite tricky - in this case we are going to have to
make a 'best guess' and try to make it minimalistic (Complex systems come
from simple rules)  approach just to get the ball rolling

James

BTW - How is the Elevator Challenge going. It was a very tough one to hand
out first up - thats why I chose it.. It is sometimes quite challenging to
push from idea to implementation and all the issues without silver bullets
that 'spring up' can be quite discouraging. I am keen to see your final
solution.





> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of Ted
> Kosan
> Sent: Sunday, January 26, 2003 6:08 PM
> To: James Caska; emb...@li...
> Subject: RE: [Embedlets-developer] RE: PLC help (plcopen.org)
>
>
> James,
>
> The paper was a great read and I also snooped around on
> their site a bit.  It is truly good to see hard core
> industrial control companies taking a deep interest in
> Java.  The SoftPLC system looks very interesting and I
> noticed that their Modlets were kind of like Embedlets.
>
>
> Ted
>
>
>
> --- James Caska <ca...@vi...> wrote:
> > Hell of an interesting link...
> >
> >
> http://www.measureanything.com/pdf/softplc/eAutomation_Endless_Pos
sibilities
> _by_Softplc.pdf
>
> James
>


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Embedlets-developer mailing list
Emb...@li...
https://lists.sourceforge.net/lists/listinfo/embedlets-developer

RE: [Embedlets-developer] RE: PLC help (plcopen.org)

[Ted K. <tk...@ya...>]

James,

The paper was a great read and I also snooped around on
their site a bit.  It is truly good to see hard core
industrial control companies taking a deep interest in
Java.  The SoftPLC system looks very interesting and I
noticed that their Modlets were kind of like Embedlets.


Ted



--- James Caska <ca...@vi...> wrote:
> Hell of an interesting link...
> 
>
http://www.measureanything.com/pdf/softplc/eAutomation_Endless_Possibilities
> _by_Softplc.pdf
> 
> James
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

RE: [Embedlets-developer] RE: PLC help (plcopen.org)

[James C. <ca...@vi...>]

Hell of an interesting link...

http://www.measureanything.com/pdf/softplc/eAutomation_Endless_Possibilities
_by_Softplc.pdf

James


> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of Ted
> Kosan
> Sent: Saturday, January 25, 2003 7:05 PM
> To: emb...@li...
> Subject: [Embedlets-developer] RE: PLC help (plcopen.org)
>
>
> James,
>
> After reading your PLC posts I spent a significant amount
> of time on the net researching the current state of the PLC
> world.  It has been a number of years since I did any
> serious PLC programming and it was interesting to see what
> new things have been developed.
>
> And... I think I hit a mother lode of information that
> looks like it could be very helpful to the Embedlets
> effort.
>
> There is an organization called PLCopen and they have
> developed a significant number of standards (both graphical
> and non-graphical) for things like ladder logic and
> functional block diagrams (FBDs).  The FBDs have some
> striking similarities to what I imagine Embedlets will look
> like and they seem to have developed solutions to problems
> that I personally was struggling with.
>
>
> Here is a quick plcopen overview:
>
> http://www.plcopen.org/intro_iec/intro_iec.htm
>
>
> and here is the main site:
>
> http://www.plcopen.org
>
>
> I am going to start studying their materials and also join
> their email list.  I am looking forward to 'picking their
> brains' and I am also interested in getting their reaction
> to possibly having their standards implemented in
> platform-independent Java.
>
>
> Thanks for the tip!
>
>
> Ted
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>

[Embedlets-developer] RE: PLC help (plcopen.org)

[Ted K. <tk...@ya...>]

James,

After reading your PLC posts I spent a significant amount
of time on the net researching the current state of the PLC
world.  It has been a number of years since I did any
serious PLC programming and it was interesting to see what
new things have been developed.

And... I think I hit a mother lode of information that
looks like it could be very helpful to the Embedlets
effort.

There is an organization called PLCopen and they have
developed a significant number of standards (both graphical
and non-graphical) for things like ladder logic and
functional block diagrams (FBDs).  The FBDs have some
striking similarities to what I imagine Embedlets will look
like and they seem to have developed solutions to problems
that I personally was struggling with.


Here is a quick plcopen overview:

http://www.plcopen.org/intro_iec/intro_iec.htm


and here is the main site:

http://www.plcopen.org


I am going to start studying their materials and also join
their email list.  I am looking forward to 'picking their
brains' and I am also interested in getting their reaction
to possibly having their standards implemented in
platform-independent Java.


Thanks for the tip!


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] Re: Rebooting your dishwasher and car...

[Ted K. <tk...@ya...>]

Andrzej,

I wonder what a reasonable strategy would be for increasing
the reliability of a system as complex as the BMW 745?  I
am fairly comfortable with the concept of unit testing the
interfaces in an application but how does one do this
across all of the systems in something like the BMW 745?

A few years ago I had a chance to dig into a 12 cylinder
BMW E32 and it was a nightmare.  Even though a number of
the electronic systems were Motorola 68HC11 based, there
were no detailed schematics available and of course source
code to any of the systems was impossible to obtain.

I can not imagine how horrible it would be to try to
trouble shoot one of the more modern automobiles.


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

RE: [Embedlets-developer] RE: PLC help

[James C. <ca...@vi...>]

Hi all,

The last post is part of a PLC - programmable Logic Controller - discussion
that has been going on in the PICLIST. I have reposted it here and home that
interested PICster's come across to talk with us about it further.

In actual fact, it occured to me a while ago that PLC's are a natural
application for the embedlet concept. Ladder logic is a standard, it is a
subset of the full embedlet concept and there is already a large existing
skillset in the ladder logic developers and systems. It makes alot of sense
for the wiring technology we come up with to support ladder logic diagrams
for generating embedlet PLC's.

I would be interested for one, to create necessary support packages for the
PLC execution 'runtime' but what would be better is if we could make this
the one and same thing as the embedlet runtime.

It might be a good place for embedlets to cut their teeth

So Ted.. consider this as a second design challenge.

Demonstrate how the embedlet wiring concept can be used to develop
executable ladder logic diagrams.


James


>

[Embedlets-developer] RE: PLC help

[James C. <ca...@vi...>]

> Any other ideas ?

Pending your time frame, if you are interested in developing a java based
solution I may be interested in assisting you

a) To use Virtual Breadboard's openVBB framework as the (free) schematic
editor of the ladder logic diagrams
b) To autogenerate java code or even better - an embedlet object heirachy
from the ladder logic diagrams for execution on the new (very very soon ) to
be released uVM PIC Java processor
c) Developing necessary java packages to support the execution of PLC style
code in the com.muvium framework

References
www.virtualbreadboard.com
www.muvium.com
http://sourceforge.net/projects/embedlets/

Jump onto the embedlets list and repost this.. it is VERY similar and
compatible with some of the work we are thinking about over there. Ted Kosan
in particular would be interested in talking about PLC applications of the
embedlets concept.

I have posted this to the embedets list as a lead in..

Just some ideas ;-)

Regards,
James Caska



> -----Original Message-----
> From: pic microcontroller discussion list
> [mailto:PI...@MI...]On Behalf Of Orbit Communications
> Sent: Saturday, January 25, 2003 10:56 AM
> To: PI...@MI...
> Subject: Re: PLC help
>
>
> We will be developing our own GUI so that license/cost issues are
> minimized.
>
> The function now is developing an efficient and simple strategy for
> tokenising the Ladder logic statements and executing them from external
> serial flash memory.
>
> The other option was to simply have a library of functions in the
> PIC as an
> "operating system" and write some pseudo-code to represent calls to these
> functions with parameters.
>
> Does anyone know where there is information that describes the output of a
> compiled ladder logic program ?
>
> Any other ideas ?
>
> Kind Regards
>
> David Huisman (CEO)
> -----------------------------------------------------------------------
> ORBIT COMMUNICATIONS - Wireless Solutions that Work
> (Telemetry, Control, Monitoring, Security, HVAC ...)
>
> Website : http://www.orbitcoms.com
> PO Box 4474 Lakehaven
> NSW 2259, AUSTRALIA
> Phone: 61-2-4393-3627
> Fax  : 61-2-4393-3685
> Mobile: 61-413-715-986
> ----- Original Message -----
> From: "William Chops Westfield" <bi...@CI...>
> To: <PI...@MI...>
> Sent: Saturday, January 25, 2003 10:21 AM
> Subject: Re: PLC help
>
>
> > > I have developed a system for one of my customers which works as
> follows:
> > >
> > > 1: Draw a ladder diagram using the schematic editor in Eagle.
> > >
> > > 2: Generate PARTLIST and NETLIST files from the Eagle drawing.
> > >
> > > 3: Parse the PARTLIST and NETLIST to 'compile' the ladder diagram into
> an
> > > intermediate 'P-Code' like language.
> >
> > That's cute.  Do you have to become an Eagle "distributer", or
> do you just
> > insist that the customer buy a copy of at least the schematic editor?
> >
> > BillW
> >
> > --
> > http://www.piclist.com hint: The PICList is archived three different
> > ways.  See http://www.piclist.com/#archives for details.
> >
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.
>
>

[Embedlets-developer] http://www.math.luc.edu/triveni/

[Gregg W. <gr...@sk...>]

Check out http://www.math.luc.edu/triveni/ for an interesting twist on =
event processing and connectability...

Gregg Wonderly

[Embedlets-developer] JAPL use scenario walk through

[Ted K. <tk...@ya...>]

JAPL (Java Abstract Peripheral Library) use scenario walk
through.

Here is a short JAPL scenario I put together in order to 
add more realism to the following Embedlet application I
posted earlier:

http://embedlets.sourceforge.net/devdocs/diagrams/embedlets_v.05.jpg

First there is a couple of paragraphs on the purpose of
JAPL and then the scenario follows.


PURPOSE OF the JAPL

The purpose of the JAPL is to allow Embedded Java code to
be compiled against a standard library of Abstract
Peripherals.  The incentive for creating a library like
this is that even though most microcontroller and computer
system peripherals are very similar, the specific details
of how these peripherals are accessed is quite diverse.

For example, the 8 bit wide I/O port is a very common
peripheral but the way that the data direction for each bit
is configured, and the manner in which the port itself is
accessed, is usually different across systems.  Even Java
based embedded systems like TINI and JStamp encapsulate
their I/O ports in proprietary classes.

NOTE: Even though the JAPL is not limited to just low level
microcontroller peripherals (its definition of peripheral
is very broad) this scenario does use such a low level
peripheral.


EMBEDLET USE SCENARIO 1 - PnP I/O module which has a JAPL
interface pre-specified at the factory.  The device will
assumed to be accessible on a PnP bus like 1-Wire.

1) Place an Outpost on the table and plug it into a
workstation that is running the Wiring Tool.  Its Outpost
Embedlet Container graphically appears in the wiring tool.

1a) A Virtual PnP Bus Adapter is also present somewhere in
the wiring tool and one of its jobs is to do the following:

a) Discover (or be pre-configured to hold) all PnP adapters
that exist in the system.  If the 1-Wire API is present
then all 1-Wire adapters in the system are encapsulated
here.  If I2C adapters, etc., are present then these too
are encapsulated.


2) Select a physical Switch Sensor module and plug it into
the Outpost (lets assume it uses a DS2406 based input
port).  The Switch Sensor has been designed at the factory
to implement the JAPL org.japl.digital.InputBit interface
and the URL* of an XML file which describes the module is
stored inside of a tagging device which is present within
the sensor.


3) The DS2406 enters the 1-Wire network, it is
automatically discovered, a OneWireContainer12 object
(thanks 1-Wire Java API!) is instantiated for it and this
object is passed to the Virtual Bus object.  The Virtual
Bus object knows all about the tagging standard so it
accesses the DS2406's internal memory and finds a URL which
points to an XML file on the Internet which holds
information about the I/O module that the DS2406 is a part
of.

Here is some information about the tagging specification:

*URLs INSIDE OF THE MODULE'S TAGGING DEVICE 

The URL which is inside of a tagging device will point to
an XML file on the Internet which will hold the following:

1) Module's name.
2) Module's manufacturer.
3) Manufacturer's URL.
4) Module's model number.
5) Fully qualified name of the JAPL peripheral that the
module implements.
6) URL of a serialized object that implements the JAPL
interface specified in step 5.  This object will contain
code that will talk to the module using whatever protocol
the device uses (in this case the 1-Wire Java API).
7) Class of the serialized object that implements the JAPL
interface specified in step 5.

For example, a DS2406 based Switch Sensor might contain the
following URL

alertsensors.com/japl/tags/CT2343.tag.xml 

which points to the following XML file:

<module>
  <manufacturer>Alert Sensors</manufacturer>
  <manufacturerURL>alertsensors.com</manufacturerURL>
  <model>ct2343</model>
  <implements>org.japl.digital.InputPort</implements>
 
<persistedPeripheralURL>alertsensors.com/japl/persisted/CT2343.xml</persistedPeripheralURL>
 
<peripheralClassURL>alertsensors.com/japl/classes/CT2343.class</peripheralClassURL>
</module>
  

4) The Virtual Bus object downloads the 
alertsensors.com/japl/tags/CT2343.tag.xml file and obtains
the persisted Java object which implements the  
org.japl.digital.InputPort interface along with its class
file.  The persisted object is deserialized into the wiring
tool container and the OneWireContainer12 object is placed
into it.  The BeanInfo class for the
org.japl.digital.InputPort is then obtained from the
japl.org site and a graphic representation of the JAPL
org.japl.digital.InputPort peripheral automatically appears
in the wiring tool.

5) The wiring tool can then be used to customize the
peripheral, attach it to the Embedlet container and then
wire it to Embedlets which hold references to JAPL 
org.japl.digital.InputPort input ports.


Ted




__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] Elevator challenge update #2

[Ted K. <tk...@ya...>]

A solution to the Elevator challenge is continuing to move
forward at a reasonable pace.  Here are some ideas that are
firming up:  

1) Embedlets live inside of the Embedlet Container and
internally they contain no connections to entities outside
of the container aside from the JAPL peripherals that they
have references to.

2) All communication with external peripherals/devices/I/O
circuits/services/backend system/ etc. is done through an
independent library of Abstract Peripherals whose
interfaces are defined in a JAPL (Java Abstract Peripheral
Library).  'Peripheral' is being used in its most general
sense here.  JAPL is to peripherals as JDBC is to databases
for any given peripheral type.  For example, one JAPL
Abstract UART peripheral can be implemented using any
physical UART, a software 'bit banger' or any other
technology.

3) Embedlets communicate with each other using Embedlet
Events.  Embedlets communicate with JAPL peripherals
primarily using direct references.  If a JAPL peripheral
needs to send an event notification then this can be done
using a JAPL Interrupt Event (just like normal peripherals,
like a UART, would do).


Here is a diagram that shows a simple Embedlet application
based upon these principles:

http://embedlets.sourceforge.net/devdocs/diagrams/embedlets_v.05.jpg

This applications monitors how often a door is opened. 
Each time the door is opened a buzzer sounds and after the
door has been opened 50 times these 50 samples are sent as
a group to a backend server for logging into a database.

The graphic solution that is being developed for the
elevator challenge is much more sophisticated than this but
the diagram does illustrate some of the Embedlet
technologies that are being evolved.

Comments on this diagram would be greatly appreciated.


Ted


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-developer] Test post...

[Andrzej J. T. <an...@ch...>]

...just trying to see if my ISP corrected my difficulty in posting to Sourceforge 
lists.

tap....tap....tap....

Is this thing on? ;-)


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

[Embedlets-developer] Rebooting your dishwasher and car...

[Ted K. <tk...@ya...>]

I am relaying this post from Andrzej because he is still
having ISP difficulties. Ted.

-----

Rebooting your dishwasher: 
     

http://www.baselinemag.com/print_article/0,3668,a=35839,00.asp
 
Thought this article is rather amusing, it does point to a
key issue of embedded software, that being reliability!
 
Something we should probably give a lot of thought to in
the design of the Outpost container architecture.
 

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

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com