Home » General (non-technical) » Project Proposals » New Proposals: Eclipse SCADA
| | |
Re: New Proposals: Eclipse SCADA [message #1066470 is a reply to message #1064327] |
Tue, 02 July 2013 18:57 |
|
It looks like there are several components under Eclipse SCADA that all have their own "fancy" name.
Looking at their list, I have the following remarks:
- Should these names really all be kept? especially since I think they will all need to go through a trademark review, even though some of them might refer to technical components that will likely evolve over time, be merged with each other, etc.
- Maybe a pure UI/SWT component like Infinity should be contributed to Eclipse Nebula, for easier consumption by 3rd parties?
- I guess that rather than a list of the technical components that are part of the initial contribution, some higher level architecture diagram would certainly help understand better the functional blocks of Eclipse SCADA: Server, Configuration, UI, Drivers implementations, ...
I am not implying these points should be solved for a successful project creation, and this can certainly worked over time as the project grows, ... this was just my 2 cents
My blog: http://blog.benjamin-cabe.com
|
|
| |
Re: New Proposals: Eclipse SCADA [message #1066500 is a reply to message #1066470] |
Tue, 02 July 2013 21:23 |
Jürgen Rose Messages: 3 Registered: June 2013 |
Junior Member |
|
|
Quote:It looks like there are several components under Eclipse scada that all have their own "fancy" name.
Looking at their list, I have the following remarks:
Should these names really all be kept? especially since I think they will all need to go through a trademark review, even though some of them might refer to technical components that will likely evolve over time, be merged with each other, etc.
Maybe a pure UI/SWT component like Infinity should be contributed to Eclipse Nebula, for easier consumption by 3rd parties?
I guess that rather than a list of the technical components that are part of the initial contribution, some higher level architecture diagram would certainly help understand better the functional blocks of Eclipse scada: Server, Configuration, UI, Drivers implementations, ...
As we mentioned in the telephone conference we probably will rename the repositories to something more meaningful. Since we are forced to separate the LGPL dependencies from the other implementations, we are going to extract the drivers from the openscada core. One idea would be to have a common repository with protocol libraries, and a separate module with driver implementations which are based on it. The protocol part could be independent from other Eclipse SCADA components, so it would be reusable within other projects without pulling in a lot of dependencies (possibly limited to mina, slf4j and some utility stuff).
Regarding the extraction of Infinity (the chart widget) in a separate project or integrating it with nebula, we already discussed this internally. Only for the moment we really would like to keep it together with Eclipse SCADA, since there is still a lot of functionality we would like to add, and we would like to have some flexibility in changing it. When the features set has reached a point where the api will stay, we are more than willing to extract it, to nebula for instance.
The slide deck (link in the wiki page mentioned above) we showed was a condensed version (concentrating on the data access part) of a larger presentation. I want to make some improvements to the large version and post it on slideshare, this should address some the issues (architectural diagram).
|
|
|
Re: New Proposals: Eclipse SCADA [message #1066699 is a reply to message #1066486] |
Wed, 03 July 2013 20:08 |
Werner Keil Messages: 1087 Registered: July 2009 |
Senior Member |
|
|
Jürgen,
Thanks for the reply and intrest.
Especially the UCUM side and unit support in text messages (or anything like
it, JSON, XML or even CSV) normally isn't more than a description. What
standardized unit catalogues like UCUM allow is to validate them against a
commonly defined and accepted code catalog without the risk of overlap or
misconception between different units.
Even calculations and a certain level of conversion is possible, e.g. things
like "mg/s" or "km/h"
Please check "eclipse.uomo" news as well as mailing lists like
science-iwg@xxxxxxxx or uomo-users@xxxxxxxx.
And the two Google Groups for Unit-API units-dev@xxxxxxxx and
units-users@xxxxxxxx.
Cheers,
Werner
"Jürgen Rose" schrieb im Newsbeitrag news:kqvfmd$v9o$1@xxxxxxxxe.org...
@Werner Keil: So far we dind't consider units, except just as descriptions,
but yes it could be beneficial to use a standardized unit representation, so
any scaling or conversion could be checked and evaluated creating error
flags, or maybe just mapping the correct name to it.
|
|
| | | | |
Goto Forum:
Current Time: Sat Apr 27 00:59:08 GMT 2024
Powered by FUDForum. Page generated in 0.04686 seconds
|