Thread: [Embedlets-dev] Some good reading....
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer
|
From: Andrzej J. T. <an...@ch...> - 2003-02-13 14:31:21
|
From eWeek, an article on the growing use of Ethernet on the factory floor. Definitely worth a read. Here's a quote from the piece: > One of the obstacles to Ethernet's acceptance at the device level is > the lack of standards at the application level. > "We decided not to use Ethernet at the I/O [device] level. There is no > real standard yet. You can't take a GE Ethernet controller and hook it > up to someone else's device," said Jan Lindstrom, vice president of > technology for printing press manufacturer KBA North America Inc., in > York, Pa. eWeek Article at: http://www.eweek.com/article2/0,3959,857161,00.asp And another one on Motorola using Linux and Java on their newest cell phones: http://news.com.com/2100-1001-984424.htm An interesting strategy from Motorola that may presage what could happen on the shop/warehouse floor. Both pieces point to potentially large and valuable market opportunities for Outpost and Embedlets. BTW....I think it's time for me to post something controversial again.....the list has been too quiet! Good thing too.....given me some uninterrupted "think time" about the spec and details of the architectural implementation. <grins> Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
|
From: Gregg W. <ge...@co...> - 2003-02-13 21:43:32
|
Andrzej Jan Taramina wrote: > eWeek Article at: > > http://www.eweek.com/article2/0,3959,857161,00.asp Since ethernet is a CSMA (carrier sense, multiple access) technology, it can never be 'instanteous' or 'hard real-time'. However, many controllers are becoming smarter and manufactures are also able to put more control at the controllers instead of at the administrative level. It will be interesting to see what happens here. I suspect that a new family of devices will evolve due to reduced cost of processing power, and the need to remove realtime control from the comms link... > And another one on Motorola using Linux and Java on their newest cell > phones: > > http://news.com.com/2100-1001-984424.htm this should be http://news.com.com/2100-1001-984424.html Reading it now... Gregg |
|
From: Brill P. <bri...@ro...> - 2003-02-14 07:20:27
|
Re: Outpost_ArchitectureDiscussionDocument_13.pdf Page: 12 (bottom) I'm a little concerned about allowing "device polling and timing" to be entirely in the domain of the embedlet service(s), if in its domain at all. I think it would be better if the embedlet service(s) *requested* specific polling "properties" from the JAPL, however polling is something that can be device and processor dependant (sometimes in the extreme). A processor or JAPL implementation should be allowed to define it's own polling rates etc... for instance, most temperature sensors require quite a bit of time to show any significant changes... the JAPL implementation will know how fast a device responds, and can tailor itself accordingly. I think what might be a slightly better approach (though I have not entirely thought it through) is if the embedlet service(s) could tell a JAPL impl. to notify it through an event when a change occurred... so for instance in the Temperature sensor example, the embedlet container would be able to give the sensor a change window, and receive an event when the actual JAPL implementation determined that it was warranted. In the case where the state of the peripheral was requested from the remote system, it would be a fairly simple task for the outpost module to store the last state and return that. Some devices of course should not be event driven, but most I can think of off the top of my head would best be implemented that way. What this means, is that the embedlet service(s) have no control over the polling or timing rates etc... which is the opposite of the current spec. discussion (and why I bring it up). Thoughts? - Brill Pappin Rogue Robotics www.roguerobotics.com |
|
From: Christopher S. <cs...@oo...> - 2003-02-14 20:07:30
|
> > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Re: Outpost_ArchitectureDiscussionDocument_13.pdf > Page: 12 (bottom) > > I'm a little concerned about allowing "device polling and timing" to be > entirely in the domain of the embedlet service(s), if in its > domain at all. > > I think it would be better if the embedlet service(s) *requested* specific > polling "properties" from the JAPL, however polling is something > that can be > device and processor dependant (sometimes in the extreme). > > A processor or JAPL implementation should be allowed to define it's own > polling rates etc... for instance, most temperature sensors > require quite a > bit of time to show any significant changes... the JAPL > implementation will > know how fast a device responds, and can tailor itself accordingly. > > I think what might be a slightly better approach (though I have > not entirely > thought it through) is if the embedlet service(s) could tell a > JAPL impl. to > notify it through an event when a change occurred... so for > instance in the > Temperature sensor example, the embedlet container would be able > to give the > sensor a change window, and receive an event when the actual JAPL > implementation determined that it was warranted. > > In the case where the state of the peripheral was requested from > the remote > system, it would be a fairly simple task for the outpost module > to store the > last state and return that. Some devices of course should not be event > driven, but most I can think of off the top of my head would best be > implemented that way. > > What this means, is that the embedlet service(s) have no control over the > polling or timing rates etc... which is the opposite of the current spec. > discussion (and why I bring it up). > > Thoughts? This is the classical 'who has control' discussion that goes on in any architecture. My recomendation would be to break the pieces down to a little lower level so that you have fine-grain, descrete functional blocks that can provide both functional requirements: 1. A sample timer (Embedlet) that issues timer events 1. I/O (JAPL or Embedlet) that just gets the data when told. Then issues a 'done' event 3. A theshold sensor that receives the 'done' event checks upper/lower bounds and issues an 'out-of-bounds' event. In this way the system can be built up from mix-and-match components that may come from different vendors and no one component has disproportionate 'control'. This also gives you the flexibility to have local independent loops that run at different rates if that is a requirement. You (the Embedlet user) gets to determine who is in control! You (the Embedlet designer) do no have to accommodate multiple, mutually exclusive requirements. > > - Brill Pappin > Rogue Robotics > www.roguerobotics.com > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Brill P. <bri...@ro...> - 2003-02-18 01:18:33
|
> In this way the system can be built up from mix-and-match components that > may come from different vendors and no one component has disproportionate > 'control'. > > This also gives you the flexibility to have local independent loops that run > at different rates if that is a requirement. You (the Embedlet user) gets to > determine who is in control! You (the Embedlet designer) do no have to > accommodate multiple, mutually exclusive requirements. Control is good... but there are situations (a lot of them) where you really don't want users to be able to mess with the internals... I guess the embedlet user does need to be able to take some control, but I think it should be limited to what the environment deems "safe" or efficient... for instance, if the embedlet container wants to poll temperature every 500uS, the JAPL implementer is not going to allow the container to force me to make a call to actually read the temperature that often (depending on the granularity and speed of the sensors etc.) because it takes up resources I need for other functions, and that I don't really want to give up to the embedlet container. So, I guess my point is that though you can delegate some control to the embedlets, in a lot of circumstances, the underlying JAPL impl. *must* keep control over itself, and prevent the embedlet(s) for putting it into an unstable or inoperative state. - Brill Pappin |
|
From: Christopher S. <cs...@oo...> - 2003-02-18 02:20:17
|
> > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > > > In this way the system can be built up from mix-and-match > components that > > may come from different vendors and no one component has > disproportionate > > 'control'. > > > > This also gives you the flexibility to have local independent loops that > run > > at different rates if that is a requirement. You (the Embedlet > user) gets > to > > determine who is in control! You (the Embedlet designer) do no have to > > accommodate multiple, mutually exclusive requirements. > > Control is good... but there are situations (a lot of them) where > you really > don't want users to be able to mess with the internals... I guess the > embedlet user does need to be able to take some control, but I think it > should be limited to what the environment deems "safe" or efficient... for > instance, if the embedlet container wants to poll temperature every 500uS, > the JAPL implementer is not going to allow the container to force > me to make > a call to actually read the temperature that often (depending on the > granularity and speed of the sensors etc.) because it takes up resources I > need for other functions, and that I don't really want to give up to the > embedlet container. I was not suggestng the the container provide fixed timing control, rather that timing embedlets provide that function and get wired to the inputs and outputs as required for polling operations. This provides for multiple local timing loops that can accommodate the particular sensor or system requirements. > > So, I guess my point is that though you can delegate some control to the > embedlets, in a lot of circumstances, the underlying JAPL impl. > *must* keep > control over itself, and prevent the embedlet(s) for putting it into an > unstable or inoperative state. Agreed, if there are time critical activities that need to have uninterrupted attention, such as receiving bits from a serial stream, then the JAPL needs to maintain timing control for the duration of the critical event. At a higher level where the output of the JAPL needs to integrate with other processes, the embedlet(s) should have the to option to control the timebase of the system. It is only at the embedlet level that the overall timing requirements are defined. This may be based on the minimum Nyquist sampling/update rate of other inputs or the outputs OR client application reporting requirements. It could be on a timeframe of milliseconds to days or weeks. In this case the JAPL may be the resource hog if allowed to run on at a fixed, high rate. The embedlet/JAPL timing specifications will need to be carefully considered in any mix-and-match design. If one embedlet is demanding resources or performance beyond those available the system is likely to fail at some point regardless of whether a particular JAPL or embedlet manages all of its internal timing needs. > > - Brill Pappin > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Brill P. <bri...@ro...> - 2003-02-18 17:43:16
|
> The embedlet/JAPL timing specifications will need to be carefully considered > in any mix-and-match design. If one embedlet is demanding resources or > performance beyond those available the system is likely to fail at some > point regardless of whether a particular JAPL or embedlet manages all of its > internal timing needs. From my point of view, the JAPL impl should know about what it can, and can't do, and be able to tell the embedlet to piss-off if its abusing the peripheral in some way. It might also simply block the call (which will be happening anyway in a threaded environment) or what ever other method is relevant in the context of the peripheral. I see this as essential to ensuring the processor is stable, regardless of what some fool (no accusations) does to the embedlet configuration... from the user perspective, the embedlet "server" is just a black box, they wouldn't have a clue about the consequences of a particular configuration, nor should they have to be concerned that they would take down the server with their own bad/incorrect code. - Brill Pappin |
|
From: Christopher S. <cs...@oo...> - 2003-02-14 20:57:33
|
> > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Re: Outpost_ArchitectureDiscussionDocument_13.pdf > Page: 12 (bottom) Bill states: >Some devices of course should not be event > driven, but most I can think of off the top of my head would best be > implemented that way. Logical functions are by nature state and not event driven. You can make them event driven by performing the logical function in response to a change, however this leads to initial state problems and race conditions. Or you can use a timer to issue an event that causes the logical deveices to poll their state and assert some output. Complex systems are usually a mix of state (polled) and event driven components. My previous post addresses this by providing the best of both. |
|
From: Brill P. <bri...@ro...> - 2003-02-18 01:29:12
|
> Logical functions are by nature state and not event driven. You can make > them event driven by performing the logical function in response to a > change, however this leads to initial state problems and race conditions. Or > you can use a timer to issue an event that causes the logical deveices to > poll their state and assert some output. Complex systems are usually a mix > of state (polled) and event driven components. Yes, I understand what you are saying... I saying that there is no way a good implementation should leave the inner workings of the hardware to the enterprise developer... not if that's who we're still targeting... I tend to think its bad practice for an API to expose everything it does... it allows to much in the way of proprietary code, security holes and simple failure from developers who don't know the caveats of a particular set of hardware. IMO the embedlets are the business logic on top of the device pool... the device pool knows what it has and what it can do, the embedlets are the place where the information from the devices are configured, processed and distributed. - Brill Pappin |
|
From: Christopher S. <cs...@oo...> - 2003-02-17 21:09:37
|
In regards to event vs state driven control: I see an issue with strictly event driven Embedlets. The scenario for an industrial control is: 1. An output (embedlet) controls a raw material supply function and must be off on startup. 2. The output is controlled by a threshold Embedlet monitoring the raw material supply level. 3. The threshold embedlet is event driven and fires when the level exceeds an upper value or drops below a lower threshold. 4. When the level is low the output should come on to start the raw material feed. When the upper level is exceeded the output should turn off to stop the supply. The problem occurs when the supply is initially low and not changing because the output is off. The threshold embedlet sees no change so the event is not fired and the output remains off... the manufacturing process cannot start. This is a case where reverse chain (state) logic is required. The output must be able to 'look' back into the logical path to determine its state. You can specifiy that every embedlet should fire its event(s) on 'start' but that would create a chaotic, eplileptic firing of events. This leads to a conclusion that, at least for logical Embedlets, they may have to process both forward (event) and reverse (state) chained logic. In addition something has to initiate the reverse logic processing such as a timer event or the start() method in the output embedlet. > > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > Re: Outpost_ArchitectureDiscussionDocument_13.pdf > Page: 12 (bottom) > > I'm a little concerned about allowing "device polling and timing" to be > entirely in the domain of the embedlet service(s), if in its > domain at all. > > I think it would be better if the embedlet service(s) *requested* specific > polling "properties" from the JAPL, however polling is something > that can be > device and processor dependant (sometimes in the extreme). > > A processor or JAPL implementation should be allowed to define it's own > polling rates etc... for instance, most temperature sensors > require quite a > bit of time to show any significant changes... the JAPL > implementation will > know how fast a device responds, and can tailor itself accordingly. > > I think what might be a slightly better approach (though I have > not entirely > thought it through) is if the embedlet service(s) could tell a > JAPL impl. to > notify it through an event when a change occurred... so for > instance in the > Temperature sensor example, the embedlet container would be able > to give the > sensor a change window, and receive an event when the actual JAPL > implementation determined that it was warranted. > > In the case where the state of the peripheral was requested from > the remote > system, it would be a fairly simple task for the outpost module > to store the > last state and return that. Some devices of course should not be event > driven, but most I can think of off the top of my head would best be > implemented that way. > > What this means, is that the embedlet service(s) have no control over the > polling or timing rates etc... which is the opposite of the current spec. > discussion (and why I bring it up). > > Thoughts? > > - Brill Pappin > Rogue Robotics > www.roguerobotics.com > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Brill P. <bri...@ro...> - 2003-02-18 01:39:56
|
> In regards to event vs state driven control: I see an issue with strictly > event driven Embedlets. The scenario for an industrial control is: Sorry guys... I don't think I was very clear... I wasn't saying it should be purely event driven (or at least that's not what I meant)... what I was getting at is that the embedlet container should not have direct/exclusive control over the drivers and the impl in general.. all it should know about anything is how to configure and read the devices, based on the contract exposed by the JAPL. - Brill Pappin |
|
From: Christopher S. <cs...@oo...> - 2003-02-18 05:43:30
|
> > Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE] > _______________________________________________ > > > In regards to event vs state driven control: I see an issue > with strictly > > event driven Embedlets. The scenario for an industrial control is: > > Sorry guys... I don't think I was very clear... I wasn't saying > it should be > purely event driven (or at least that's not what I meant)... what I was > getting at is that the embedlet container should not have direct/exclusive > control over the drivers and the impl in general.. all it should > know about > anything is how to configure and read the devices, based on the contract > exposed by the JAPL. Brill, Your point is accepted. I was digressing to a more general discussion of event vs state driven systems because I have run into some issues on this front. > > - Brill Pappin > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Embedlets-developer mailing list > Emb...@li... > https://lists.sourceforge.net/lists/listinfo/embedlets-developer > |
|
From: Brill P. <bri...@ro...> - 2003-02-18 17:43:24
|
> Your point is accepted. I was digressing to a more general discussion of > event vs state driven systems because I have run into some issues on this > front. I understand, been in a few heated ones on this subject myself ;) - Brill Pappin |
Thanks for helping keep SourceForge clean.
X