Thank you for the references.  

"Two-tier" here means that UI (in this project) is running in browser. We have 
a server that provides "logic" (model for UI) and a client that just represents 
and allows to control that model (the latter translates those control actions 
into commands for devices it controls). Over the longer term, there could be 
different types of clients (desktop, mobile, etc.).

…And one more thing: We see HMI in a wider perspective then just SCADA, as this 
approach (I hope) can be applied to network management, building automation, 
time and attendance etc. All these applications have many common aspects and it 
would great to extract them to an extensible platform that allows to build any 
kind of these systems or even their combinations. And I see that Smalltalk is 
the best tool to build such a platform today …Except maybe data-acquisition 
part as it does not have sufficient mass of libraries for different protocols. 
So, in fact I see a three-tier system: data-acquisition subsystem, business 
logic subsystem, and UI subsystem with at least two of them written in 
Smalltalk.

So, that was the inspiration for the project that I suggested to Rustem as a 
term project some time ago and now he translated to the GSoC proposal.   

BTW, the project does not have the second mentor yet.


Best regards,
Dennis Schetinin
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Tuesday, 3 April 2012 г. at 18:54, Ben Coman wrote:

>  
> I am an electrical engineer whose work includes SCADA programing for  
> operator interfaces of industrial plants using Citect [1] and a bit of  
> Wonderware [2]. Both of these products include very nice sample  
> projects for their tutorials - which would provide a student a good  
> introduction to the functionality required of a HMI development tool.
>  
> What do you mean two-tier HMI? In my work, tier1 would be a PLC  
> containing the running control model of the plant, providing measured  
> values to the control logic programmed in the PLC and driving relays and  
> actuators. Tier2 is the HMI that provides the mimic of the PLC as a  
> graphical representation of the plant, colourizing warning and alarm  
> conditions, fill levels of tanks and allowing the operator to send  
> commands to the PLC to start machinery. Something doing this based in  
> Smalltalk would be wonderful.
>  
> [1]  
> http://www2.schneider-electric.com/sites/corporate/en/products-services/automation-control/products-offer/range-presentation.page?c_filepath=/templatedata/Offer_Presentation/3_Range_Datasheet/data/en/shared/automation_and_control/citect_scada.xml#
>  
> [2] http://global.wonderware.com/EN/Pages/WonderwareInTouchHMI.aspx
>  
> Dennis Schetinin wrote:
> > So, here is the proposal:  
> >  
> >  
> > Name: Khubbatov Rustem
> >  
> >  
> > Difficulty Level: Intermediate
> >  
> > Description
> > A framework for building Human-Machine Interfaces with Pharo back-end 
> > providing model, and presentation front-end in Amber.  
> >  
> > Technical Details
> >  
> >  
> > A concrete task that should be implemented with this project is a prototype 
> > of UI for network management system or SCADA. Server-side (Pharo) will 
> > simulate network components and their data, and provide relevant events for 
> > client (Amber). The latter will present network items, their state and 
> > associated information, and provide UI to control them. An important part 
> > of this system is a communication layer between Amber and Pharo.
> >  
> >  
> > Benefits for the Student
> >  
> >  
> > The student will gain experience in building client-server applications 
> > with advanced UI and providing two-way communication between client and 
> > server.
> >  
> >  
> > Benefits for the Community
> >  
> > An ability to create highly interactive web-based applications is a 
> > must-have feature for any modern development system. Amber is a bleeding 
> > edge in this area in Smalltalk world. A good communication layer between 
> > Amber and (for example) Pharo is a very appealing decision for building 
> > complex client-server systems.  
> >  
> >  
> >  
> >  
> >  
> > Best regards,
> > Dennis Schetinin
> > Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
> >  
> >  
> > On Monday, 2 April 2012 г. at 21:47, Janko Mivšek wrote:
> >  
> > > Hi Dennis,
> > >  
> > > I'd suggest to go ahead. This is first Amber-related project, so it seems 
> > > even more interesting. But hurry up. Let Rustem prepare the proposal and 
> > > you post here then we'll open the project page.
> > >  
> > > Best regards
> > > Janko
> > >  
> > > On Mon, Apr 2, 2012 at 7:41 PM, Dennis Schetinin <[email protected] 
> > > (mailto:[email protected])> wrote:
> > >  
> > > > Rustem Kkubbatov (http://gsoc2012.esug.org/rustem-khubbatov), another 
> > > > student I mentor in Tver State University, decided to try his luck with 
> > > > a project for GSoC. The problem is he can't currently choose a better 
> > > > approach.  
> > > >  
> > > > The original idea is to build a two-tier Human-Machine Interface (HMI) 
> > > > system (which can be used in a wide range of projects) with Pharo image 
> > > > as back-end (where a model lives) and Amber-based client as a 
> > > > front-end. But this thing seems to be "a little bit" too large for 
> > > > GSoC, isn't it?  
> > > >  
> > > > An alternative task could be to build a framework for message 
> > > > exchanging between Pharo and Amber. I could be the first mentor for a 
> > > > project based on original idea, or the second/first (depending on if 
> > > > anyone interested) for communication framework.  
> > > >  
> > > > Any ideas and advices are welcome (ASAP). Thank you in advance.
> > > >  
> > > > Best regards,
> > > > Dennis Schetinin
> > > >  
> > > >  
> > > >  
> > >  
> > >  
> > >  
> > >  
> >  
> >  
> >  

Reply via email to