Sim IJskes - QCG wrote:
Peter Firmstone wrote:
Anyone have any thoughts about real time java threads? EtherCAT is
real time ethernet, a Jini service that runs on a real time thread,
over real time EtherCAT with JERI and clients running on real time
threads. That would be more realistic in an industrial environment
(ubiquitous computing) than a Jini Toaster yes? We seriously need to
remove all and any references to Toasters, coffee machines etc in
documentation.
EtherCAT, do you mean the fieldbus type?
Yep
Jini certainly looks like a good communications platform for SCADA
solutions. All one needs is a small ARM-7 based sensor/controller and
GCJ for creating a flashable image and your on the road.
Anybody here know of such a scenario in the wild?
Nope be interesting to see though, if it exists. GCJ 4.0 compiles to
native code. Not sure how to do dynamic class loading for service proxy's.
I'm looking at Sun's RTSJ and Embedded Industrial x86 at the moment. My
guess is that Oracle wont open it, even though Sun originally intended
to. Java looks ideal for embedded. Although at this stage I have no
intent of utilising Jini on real time threads.
However the thought exercise is interesting:
Jini Services and clients wouldn't need to be run on real time threads
unless they were part of real time software implementations. For
classes on real time threads (RTSJ) , there is an initialisation stage
where all bytecodes for class files will be pre compiled to avoid
hotspot, so a service could potentially run on a real time thread.
Simple proxy's could be pre compiled in the initialisation stage,
limiting the client to the services determined at initialisation.
A person might rightly suggest the 8 fallacy's of distributed computing
as being a problem. One would tackle this by providing a time guarantee
for service discovery. So in a redundant network topology utilising
EtherCAT, one could have realtime services and simple proxy clients pre
determined at initialisation time, the service would actually form part
of the redundancy system, upon catching an exception, the lookup service
would provide the location of an alternate service, utilised in
instances where redundant sensors or functions were in place, made
available through Jini services. The real time service might remove its
entry from lookup once it has reached a load level that limits the real
time guarantees. There are a number of time guarantees that need to be
considered, such as network latency (according to the doc's EtherCAT has
low latency, distance and load are limiting factors) and Service load.
Perhaps with a dynamic smart proxy, one might initially use a simple
service proxy, where a server performs work subject to time guarantee's,
until the smart proxy is compiled in the background on a non real time
thread and loaded onto a real time thread when ready.
Perhaps the real time service lookup would need to be a totally
different lookup service mechanism, specific to real time, that could
coexist in the same space as the existing Jini Service Discovery /
lookup spec. The River framework would have to check if a service or
client registering for Real Time services were running on real time
threads and whether the network supported Real Time constraints. A
distinction would need to be made between soft and hard real time.
http://www.ciss.dk/download/Slides%20Martin%20Astradsson.pdf
I would love to work on a SCADA kernel completly written in Java.
Yes...
Cheers,
Peter.
Gr. Sim
