Analysis and design of a server-side Web architecture for HMI Embedded Systems

(1)

POLITECNICO DI MILANO

Facoltà di Ingegneria dell’Informazione

POLO REGIONALE DI COMO

Corso di Laurea Specialistica in

Ingegneria Informatica

Analysis and design of a server-side Web

architecture for HMI Embedded Systems

Relatore: Prof. Fraternali Piero

Correlatore: Ing. Brambilla Marco

Tesi di laurea di: Arcara Luca

matr. 666528

(2)

Italian abstract

Traduzione del capitolo “Introduction”

In questi ultimi anni, la diffusione e l’importanza dei sistemi embedded ha subito una notevole crescita dovuta alla disponibilità di tecnologie e sistemi adatti a diversi contesti di applicazione. Il significato intrinseco di sistema embedded consiste nel concetto di dispositivo progettato per essere utilizzato in contesti particolari e poco comuni; un sistema embedded risulta quindi essere ideale quando è in grado di adattarsi al più alto numero di situazioni. In questo contesto, i dispositivi HMI (Human Machine Interface) rappresentano validi strumenti per gestire diversi tipi di sistemi complessi quali impianti di produzione, reti o sistemi integrati di gestione degli edifici; questi tipi di soluzione possono essere controllati in maniera semplice ed efficace da un operatore attraverso i dispositivi HMI.

Il mercato HMI sta seguendo un andamento che lo sta portando ad un approccio completamente diverso nella gestione e visualizzazione dei dati:

• un primo passo è consistito nell’utilizzare strumenti di visualizzazione più potenti (avendo a disposizione schermi a colori e ad alta risoluzione) e pannelli di controllo interattivi (non solamente con tasti ma anche con touch screen);

• a causa delle sempre maggiori capacità, e nonostante stringenti requisiti di business e vincoli fisici, i dispositivi HMI stanno andando verso un’unificazione con il mondo dei sistemi basati su PC; questo è un esempio di come il concetto di sistema embedded sia basato su un continuo compromesso tra funzionalità e prestazioni;

• il mercato HMI si sta anche dirigendo verso applicazioni capaci di fornire caratteristiche quali la gestione distribuita di sistemi complessi (accesso remoto), l’adattamento automatico in base al diverso canale di accesso (PDA, cellulari, PC) e gestione della mobilità (wireless LAN).

Parallelo al contesto HMI vi è la presenza del vasto universo delle applicazioni informatiche; questo mondo si sta evolvendo seguendo il fenomeno della convergenza digitale, il quale è caratterizzato da:

• dispositivi e applicazioni sempre più potenti e flessibili, e capaci di garantire remotizzazione, multicanalità, mobilità, personalizzazione e adattività;

• numerose specifiche di standard tecnologici (XML, HTML);

• successo di interfacce utente e architetture standard (browser, grafica vettoriale, architetture basate su IP, architetture a tre livelli).

Inoltre, negli ultimi tempi la capacità di gestire le informazioni in maniera coordinata e integrata costituisce un fattore di sempre più rilevante importanza.

E’ in questo contesto che il progetto Poli-HMI ha origine; un progetto che è nato da un accordo tra una società HMI (identificata in questo documento con il nome HMI-COMPANY a motivo delle informazioni confidenziali in esso contenute) e il Polo Regionale di Como del Politecnico di Milano; una sinergia capace potenzialmente di fondere esperienze in campi completamente diversi del vasto mondo delle applicazioni informatiche. HMI-COMPANY opera nel mercato industriale da molto tempo, mentre il Politecnico è sempre stato all’avanguardia rispetto alle più nuove evoluzioni tecnologiche nel mondo dell’informatica, e, nello specifico del Polo Regionale di Como, delle applicazioni Web e multi canali.

Poli-HMI è un interessante esperimento ed è anche un esempio di collaborazione tra il mondo dell’università e dell’industria, il cui valore è aumentato dal fatto che nasce da un

(3)

Il fine del progetto Poli-HMI è di portare forti innovazioni nel mondo HMI, con l’idea di rinnovare il portafoglio prodotti di HMI-COMPANY; l’obiettivo è di essere in grado di garantire nuovi dispositivi che:

• supportino caratteristiche quali remotizzazione, multicanalità, mobilità, personalizzazione e adattività;

• lavorino con interfacce utente standard (browser);

• siano costruiti su architetture basate sul Web;

• utilizzino standard e framework diffusi nel mondo del Web come XML, HTML, SVG e Flash.

Questa attività di rinnovamento industriale aspira a reingegnerizzare il modello architetturale degli attuali prodotti HMI-COMPANY; in particolare, l’architettura dovrebbe migrare dall’attuale modello monolitico verso un più flessibile modello Web.

Il progetto Poli-HMI copre molti aspetti riguardanti le applicazioni informatiche, prendendo in considerazione sia problematiche software che hardware. Per ciò che concerne il sistema software che si intende realizzare, l’idea principale è di sviluppare una soluzione Web client-server (come mostrato nella figura successiva) configurabile tramite un apposito configuratore. Una volta installata, l’applicazione consentirà agli operatori di accedere al dispositivo lavorando direttamente sul congegno stesso (compact configuration con client e server che vengono eseguiti sullo stesso dispositivo HMI-COMPANY) oppure attraverso connessione Internet remota (detached configuration con client e server che vengono eseguiti su terminali differenti).

LAN

Poli-HMI server

Presentation layer (produzione markup e oggetti di interfaccia)

Business layer (elaborazione dati XML, personalizzazione, adattamento dinamico interfacce)

Data/field interface layer (gestione profile utente, dati di contesto, raccolta dati campo, emissione comandi al campo) Sistema di modellizzazione dell’interfaccia Modello dell’interfaccia Internet Poli-HMI client (browser) Poli-HMI client (terminale remoto) Poli-HMI client (PDA + micro browser)

HMI standalone Ambiente controllato

(impianto, edificio, museo)

Architettura proposta per il nuovo sistema Poli-HMI

Questa tesi consiste nell’analisi dei requisiti e nel design dell’architettura server su cui basare il nuovo sistema Poli-HMI; lo studio è stato effettuato seguendo il modello a cascata per lo sviluppo di software, ossia un processo diviso in fasi, quali analisi, design, implementazione, test, integrazione e manutenzione. In realtà, l’approccio è stato leggermente diverso da quello classico definito nel modello a cascata, in quanto ha considerato anche una fase di analisi di tecnologie, studio di un sistema preesistente e sviluppo di prototipi.

(4)

Il modo in cui questa tesi è stata sviluppata e i punti principali che sono stati approfonditi possono essere sintetizzati nel seguente elenco:

1. un tema centrale è stata l’analisi delle tecnologie che supportano lo sviluppo di applicazioni server. Lo studio si è reso necessario in quanto il progetto Poli-HMI consiste in un approccio completamente nuovo nel mondo dei sistemi embedded, infatti ci sono poche applicazioni embedded esistenti che supportano funzionalità server. Il risultato di questa sezione della tesi si è concretizzato nella proposta di una tecnologia server da utilizzare come base per lo sviluppo successivo del progetto; 2. parte di questo lavoro è stato dato dall’analisi dell’attuale applicazione

HMI-COMPANY; si è reso necessario effettuare questo passo, in quanto si è considerato primario e utile, prima di partire con lo sviluppo del nuovo sistema, conoscere come il sistema HMI-COMPANY è strutturato e quali funzionalità offre;

3. una volta concluse le due analisi sopra descritte è stato possibile partire con la definizione dei requisiti software del nuovo sistema. Allo scopo di ottenere una migliore specifica dei requisiti funzionali, si è preferito effettuare anche l’analisi degli Use Case;

4. dopo la definizione dei requisiti è stato preso in considerazione il design della struttura principale su cui basare il nuovo sistema Poli-HMI. Il design è stato sviluppato seguendo un approccio funzionale, caratterizzato dall’evidenziazione, per ogni singola funzionalità del sistema, solo dei componenti coinvolti;

5. infine, è stato inoltre sviluppato un prototipo della nuova applicazione Poli-HMI, allo scopo di testare alcune funzionalità della nuova architettura e la sua fattibilità.

I capitoli contenuti in questo documento sono:

• capitolo 2 - Poli-HMI project overview: contiene una spiegazione più approfondita del progetto sviluppato in collaborazione tra HMI-COMPANY e il Politecnico di Milano;

• capitolo 3 - Server-side Web technologies for embedded systems: analizza tutte le tecnologie che supportano lo sviluppo di applicazioni server-side che possono essere eseguite su sistemi embedded, più nello specifico su sistemi che supportano il sistema operativo Windows CE;

• capitolo 4 - HMI-COMPANY run-time architecture: contiene uno studio dell’architettura run-time che al momento è installata sui prodotti HMI-COMPANY;

• capitolo 5 - Software Requirement Specifications: specifica i requisiti software del nuovo sistema server-side, supportando inoltre questa analisi con lo studio degli use case;

• capitolo 6 - Poli-HMI server run-time architecture: definisce il design della parte server del run-time Poli-HMI;

• capitolo 7 - A prototype of the Poli-HMI architecture: descrive il prototipo sviluppato per effettuare un primo test del nuovo sistema;

• capitolo 8 - Conclusions and future works: contiene un riassunto del lavoro svolto e presenta alcuni possibili sviluppi futuri.

(5)

Ringraziamenti

Mi piacerebbe esprimere gratitudine in questo breve spazio a coloro che mi hanno aiutato a raggiungere questo passo importante della mia vita. Un grazie anche per avermi sopportato,

soprattutto in questo ultimo periodo in cui sono stato poco disponibile.

In particolare vorrei ringraziare coloro che in prima persona hanno supervisionato il mio lavoro quali il Professore Fraternali e l’ingegnere Marco Brambilla, che mi hanno assistito

nello sviluppo di un approccio ingegneristico alle problematiche di questo progetto. Un ricordo speciale a tutti i ragazzi, compagni di viaggio in questi 5 anni di università. Grazie

anche a tutti i colleghi del Politecnico con cui ho collaborato in questi mesi di lavoro: Luca, Davide, Alberto, Antonio, Tommaso, Mattia, Giovanni; in particolare però coloro con cui ho

condiviso anche il lavoro e i numerosi pranzi ossia Marco, Paolo e Alessandro. Un ringraziamento anche a Paolo e Davide, i ragazzi dell’ufficio ospiti, che hanno contribuito ad

allietare questi mesi di tesi, e a Natalino per la disponibilità mostratami nel rispondere alle mie domande.

Come non ricordare poi la mia famiglia a cui devo maggiormente il fatto di aver concluso gli studi universitari e che mi ha sopportato in questo periodo in cui sono stato poco presente.

Un grazie speciale per la revisione del documento di tesi a mia madre, Michele, Anna, Daniele, Angela, Marco, Paolo, Marco e Alessandro.

(6)

4.3 INTERNAL DEVICE MANAGERS...41 4.3.1 INTRODUCTION...41 4.3.2 DATA BUFFER...42 4.3.3 CONFIGURATION...43 4.3.4 MANAGED VARIABLES...43 4.4 DATA SERVER...43 4.4.1 INTRODUCTION...43 4.4.2 TAGS...44 4.4.3 EXPORTED METHODS...44 4.5 APPLICATION MANAGERS...45 4.5.1 INTRODUCTION...45 4.5.2 PAGE MANAGER...46 4.5.3 GRID VIEWS...47 4.5.4 ALARMS MANAGER...48 4.5.5 RECIPES MANAGER...49 4.5.6 SCRIPTING...49

4.6 EVOLUTION OF CURRENT ARCHITECTURE...50

5 SOFTWARE REQUIREMENT SPECIFICATIONS ... 51

5.1.1 OVERVIEW OF THE NEW ARCHITECTURE...52

5.2 REQUIREMENT ANALYSIS AND SPECIFICATIONS...54

5.2.1 NON FUNCTIONAL REQUIREMENTS...54

5.2.2 FUNCTIONAL REQUIREMENTS...58

5.2.3 SUMMARY OF CLIENT-SIDE SOFTWARE REQUIREMENT SPECIFICATIONS...67

5.3 USE CASES...69

5.3.1 USER GROUP IDENTIFICATION...69

5.3.2 GENERAL USE CASE DIAGRAM...70

5.3.3 USE CASE SPECIFICATIONS FOR OPERATIVE USERS...72

5.3.4 USE CASE SPECIFICATIONS FOR ADMINISTRATIVE USERS...83

5.3.5 USE CASE SPECIFICATIONS FOR THE GENERAL SYSTEM...87

6 POLI-HMI SERVER RUN-TIME ARCHITECTURE... 89

6.1.1 PREMISES...89

6.2 NEW SYSTEM GENERAL OVERVIEW...89

(9)

6.4.2 SESSION...94

6.4.3 LOGIN...94

6.4.4 AUTHENTICATION...95

6.4.5 PAGES CONFIGURATION FILE...96

6.4.6 FIELD DATA RETRIEVAL...99

6.4.7 ALARMS MANAGEMENT...100

6.4.8 VARIABLES VALUE REQUEST...101

6.4.9 COMMANDS EXECUTION...104

6.4.10 LOGGING...105

6.5 DESIGN REVISION...106

7 A PROTOTYPE OF THE POLI-HMI ARCHITECTURE... 107

7.1 PROTOTYPE SIMULATING THE CONTROL OF A MILK PLANT...107

7.1.1 REQUIRED RESOURCES...108

7.2 A PROTOTYPE FOR THE POLI-HMI SERVER ARCHITECTURE...108

7.2.1 REQUIRED RESOURCES...109 7.3 RESULTS...110 8 CONCLUSIONS ... 111 8.1 FUTURE DEVELOPMENTS...112 9 REFERENCES... 113 9.1 WEB SITES...113

(10)

1 INTRODUCTION

Nowadays, diffusion and importance of embedded systems are dramatically increasing due to availability of new technologies and systems that are suitable for many different contexts of application. The intrinsic meaning of embedded system consists in a device designed to be used in particular and uncommon contexts. An ideal embedded system should be able to fit to the highest number of situations.

In this context, HMI (Human Machine Interface) devices are valid instruments for managing different types of complex systems like production plants, networks or Computer Integrated Building systems. They allow users to control these kinds of systems in a simple and effective way.

HMI market has followed a trend that is bringing it to a completely different approach in the way data are visualized and managed:

• a first step has consisted in using more powerful view tools (having high resolution with colours) and interaction panel control (with not only keys but also touch screens);

• because of their growing capabilities, even with tight business requirements or physical constraints, HMI devices are going towards a unification with the world of PC based systems; this is an example of how the concept of embedded systems is based on the continuous compromise between functionalities and performances;

• it is also directed towards applications able to provide features such as distributed management of complex systems (remote access), automatic adaptation to different channels (PDAs, mobile phones, PCs) and mobility management (wireless LAN). Parallel to the HMI context there is the huge universe of computer applications; this world is evolving according to the digital convergence phenomena, that is characterized by:

• devices and applications that are more and more powerful and flexible, till being able to guarantee remotization, multi-channel systems, mobility, personalization and adaptivity;

• the well-established definition of many technological standards (XML, HTML);

• the success of standard user interfaces and architectures (browsers, vector graphics, IP-based architectures, three-tiers architectures).

Furthermore, nowadays the capability to provide an integrated and coordinated management of information is becoming more and more important.

It is in this context that the Poli-HMI project takes place; a project that was born from an agreement between an HMI company (referred in this document as HMI-COMPANY due to the contained confidential information) and the Campus of Como of the Politecnico di Milano. It is a synergy that can potentially merge experiences based on completely different aspects of the wide world of computer applications. HMI-COMPANY has been operating in the industrial market for a long time, while the Politecnico has been always up-to-date with the newest technologic evolution of the computer science world, and, specifically at the Campus of Como, with Web and multi-channel applications.

This project called Poli-HMI is an interesting experiment and an example of collaboration between university and industrial companies, which value is raised by the fact that it comes from an agreement between two complete different approaches in facing changes and evolution: HMI-COMPANY has a traditional culture, while the Politecnico is more oriented to innovation, always using an engineering-based methodology able to identify and evaluate

(11)

The goal of the Poli-HMI project is to apply radical innovations to the HMI world, with the idea to strongly renovate the HMI-COMPANY products portfolio; the plan is to be able to guarantee new devices:

• supporting features such as remotization, multi-channel systems, mobility, personalization and adaptivity;

• working with uniform user interfaces (browser);

• built with a Web-based architecture;

• using well-established standards and frameworks in the Web world like XML, HTML, SVG and Flash.

Hence, this industrial innovation activity aims at the re-engineering of the architectural model of the current HMI-COMPANY products; in particular, the architecture should move from the current monolithic model towards a more flexible Web system.

The Poli-HMI project covers many aspects of computer applications, considering both hardware and software solutions. Regarding the software system that is supposed to be implemented, the main idea is to develop a Web client-server application (as it is shown in figure 1.1) that can be configured by means of a design tool. Once deployed, the application will allow the users to access the device through standalone mode (compact configuration with client and server running on the same HMI-COMPANY device) and also through a remote Internet connection (detached configuration with client and server running on different hosts).

LAN

Poli-HMI server

Presentation layer (mark-up and interface objects production)

Business layer (XML data elaboration, personalization, interfaces dynamic adaptation)

Data/field interface layer (user profile management, context and field data collection, commands to the field emission) Interface modelization system Interface model Internet Poli-HMI client (browser) Poli-HMI client (remote terminal) Poli-HMI client (PDA + micro browser)

HMI standalone Controlled environment

(plant, building, museum)

Figure 1.1: Proposed architecture for the Poli-HMI system

This thesis aims to deal with the requirements analysis and the design of the server-side architecture on which basing the new Poli-HMI system; the study has followed a modified waterfall model for software development, that is a process divided into phases, such as requirement analysis, design, implementation, testing, integration and maintenance. The approach has been slightly different from the classical waterfall model, as it has considered also a phase of technology analysis, existing system study and prototypes development.

(12)

The way this thesis has been developed and the main points that have been studied in depth can be summarized in the following list:

1. a central theme has been the analysis of the technologies supporting the development of server-side applications. This study has been necessary because the Poli-HMI project considers a completely new approach in the embedded systems world, in fact there are few existing embedded applications supporting server functionalities. The goal of this part of the thesis has been the proposal of a server technology to be used during the following development of the project;

2. part of this work has consisted in the analysis of the current HMI-COMPANY application; this step has been performed because it has been considered necessary and also useful, before starting with the new system development, to work out how the HMI-COMPANY system is structured and which functionalities it offers;

3. after finishing these two analyses, it has been possible to start defining the software requirements of the new system. In order to obtain a more complete specification of the functional requirements, it has been preferred to perform also a Use Case analysis;

4. after the definition of the requirements, the design of the main structure on which base the new Poli-HMI system has been considered. The design has been developed following a functional approach, that is to highlight, for any functionality of the system, only the components involved in the execution of such functionality;

5. finally, a prototype of the new Poli-HMI application has been developed, in order to test some functionalities of the new architecture and its feasibility.

The chapters composing this document are:

• chapter 2 - Poli-HMI project overview: it contains a deeper explanation of the project developed with the collaboration of HMI-COMPANY and the Politecnico di Milano;

• chapter 3 - Server-side Web technologies for embedded systems: it analyses all the technologies supporting the development of server-side applications that can run on embedded systems, in particular on systems based on Windows CE O.S.;

• chapter 4 - HMI-COMPANY run-time architecture: it contains a study of the run-time architecture that at the moment is deployed on the HMI-COMPANY products;

• chapter 5 - Software Requirement Specifications: it specifies the software requirements for the new server-side system, supporting also this analysis by means of the study of use cases;

• chapter 6 - Poli-HMI server run-time architecture: it defines the design of the Poli-HMI server-side run-time;

• chapter 7 - A prototype of the Poli-HMI architecture: it explains the prototype developed for a first test of the new system;

• chapter 8 - Conclusions and future works: it contains a summary of the work that has been done and some suggested future development lines.

(13)

2 POLI-HMI PROJECT OVERVIEW

This work is part of the Poli-HMI project born from the collaboration between HMI-COMPANY and the Politecnico di Milano.

The project aims at the analysis, development and prototyping of a new generation of HMI (Human Machine Interface) devices for applications of industrial automation, building automation, home and general system control, with advanced features such as personalization, mobility, multi-channel, adaptive and remote systems.

These advanced features shall be studied and inserted inside the company products portfolio; hence, the project considers also a study of the current state of the company from different points of view: products, technologies and production processes. Afterwards the research activity aims at the evaluation of the possible methods and interesting technologies. It is foreseen to reach these project goals through an effort in innovation oriented toward two main directions:

1. the functional and architectural revision of the HMI-COMPANY “traditional” products portfolio addressed to the industrial automation market;

2. the products flexibility derived from the introduction of the above listed features.

2.1 HMI-COMPANY

HMI-COMPANY is a product company that includes in its products portfolio industrial HMI panels; in particular it sells Windows CE touch screen terminals.

These products are also supported by two different kinds of applications:

• configuration software: it is a software provided by HMI-COMPANY that allows the developer to design the model of the plant and to describe the user interface that he/she wants to visualize on the operator panel. Through this single software the user can program all his/her devices. There are different types of configuration software according to the devices they configure;

• panel-side software: it is a software working at run-time which is able to understand and execute the files generated from the configurator software. Two separated layers cooperate at run-time: data acquisition and presentation.

2.2 Project

Overview

2.2.1 Current view of industrial applications

An HMI (Human Machine Interface) is a device that, placed inside a complex data system (for example a company network, a group of production plants or an advanced system of Computer Integrated Buildings), provides the operator an interface for visualizing and interacting with the information contained within the same system.

Hence, HMI regards extremely effective tools for data monitoring and management, that allow the operator to visualize the information, but also to modify the plants state through the introduction of data and values into the same HMI devices.

Nowadays, in real terms, these HMI tools allow only a local data monitoring and management; this means that it is possible only when the operator is present near the field that is locally linked to the application or the control server. The interaction is performed using a keyboard or a touch screen that let user to move through the different tags or pages configured in the same HMI device.

(14)

Lately, it is getting more and more urgent the requirement to visualize, control and interact at a data and information level in a remote context: the problem is that, at the moment, it does not exist a remote HMI environment able to obtain acceptable results in the presence of high amount of data and different representations.

2.2.2 Market and technologies trends evolution

The HMI market trend reflects the evolution directions introduced by digital convergence phenomenon in other sectors, such as consumer informatics and management informatics. In these fields, there has been a double evolution:

• The applications and devices are getting more and more flexible and powerful, using the hardware capacity and network connection that continuously increase their performances. Flexibility and power are embedded in the following features:

o remotization: the possibility that the same application can be accessed in a standalone mode, on a local network or on the Internet/Web;

o multi-channel system: the possibility that the same application can be viewed on different devices (PC, mobile phone, PDA, smart phone, dedicated devices, etc.);

o mobility: the ability to support mobile users, connected to the application according to procedures different from the ones used in systems based on local or fixed geographic networks;

o personalization: the ability of an application to serve different contents and commands to different users according to their different characteristics;

o adaptivity: the ability of an application to serve different contents and commands to the same user in different moments, according to the interaction context (place, day hour, etc.).

There is an increasing presence of these features inside computer applications.

• The user interfaces and the application architectures have reached a uniform level and some technological standards have imposed themselves on the international scenario; between them there are:

o the use of standard browsers as universal interface for accessing applications;

o the use of architectures based on the IP protocol (fixed or mobile) as an instrument for local and remote connectivity;

o the use of software architectures with three tiers (data, business and presentation) for separating the user interface from the other application functionalities;

o the adoption of mark-up languages (HTML, XML, SVG) for data exchange and contents visual rendering;

o the adoption of architectures based on Web services for the development of distributed applications based on the HTTP protocol.

This evolution has not completely reached the Italian market of HMI products for industrial automation, due to the strong presence on the field of traditional devices and to the conjunctural difficulties of the small/medium companies in elaborating the investment plan necessary to reconvert their own automation infrastructures. Nevertheless, in a medium term the evolution towards HMI devices supporting the features above described will unavoidably

(15)

2.2.3 The identified opportunities

HMI-COMPANY recognizes in the current market situation and the evolution trends above described a double business opportunity:

• the functional and architectural revision of the HMI-COMPANY “traditional” products portfolio for the industrial automation market will allow the company to offer a better service to its customers and, as a consequence, to make stronger its current core business, facing the international competition;

• the products flexibility as a consequence to the introduction of features like remotization, mobility, multi-channel system, personalization and adaptivity will let HMI-COMPANY to access new markets. In particular, the following sectors are considered to be more strategic:

o Building Automation and Computer Integrated Building: it regards integrated systems for complex building management, able to provide the operator with an interface for data visualization and for performing commands to control the building;

o Home Automation: it regards building automation applications provided for the final user; their goal is to let the user to remotely and locally control the home functioning parameters and to perform video surveillance;

o Mobile applications dedicated devices: it regards applications that require special devices for a mobile access to the information, because of the particular use made by the user.

2.2.4 Current offer limitations of HMI-COMPANY and the HMI market

The current products portfolio of HMI-COMPANY and the other principal players in the HMI market is strongly oriented toward traditional applications of industrial automation. The typical architecture of an HMI system is depicted in the following figure.

Configuration parameters

LAN

Controlled

plant

HMI

User interface

Control logic

Interface with the field

System for interface configuration (offline)

Figure 2.1: Overall architecture of the current HMI products

The above depicted architecture is optimized for the traditional applications of industrial automation that require the installation of the HMI device on the controlled machine or in a network local to the plant; this architecture presents some limitations for what concerns remotization, mobility, multi-channel system, personalization and adaptivity:

• the access is limited to the standalone use on the controlled machine or the local network;

(16)

• the user interface uses a proprietary program and is not based on standard technology (browser and mark-up languages);

• the software architecture does not aim to make the presentation independent from the business logic. Even if the two software layers are distinct, the lack of a “neutral from presentation” representation of the information and the commands implies that the logic and the user interface objects are not perfectly isolated from each other;

• the interface configurability, even if allowed by the configuration system, does not adapt contents and interaction commands to access devices belonging to very different typologies, such as a PC provided with a wide screen and a PDA;

• mobility absence: the application is designed for being accessed locally or in a fixed network and does not take into consideration mobile access features (band limitations, discontinuity of the link, limited I/O apparatus);

• personalization absence: the interface configurability is static and does not take into consideration the preferences of the single user;

• adaptability absence: contents and commands that are present in the interface are not adaptable to the context in which the interaction happens.

Furthermore, an evaluation of HMI-COMPANY and HMI market has highlighted also the following aspects:

• HMI-COMPANY appears to lose the pace with innovation with respect to the new technologies and features. This is particularly clear for Web-based features, such as emailing, messaging, remotization of interfaces, browser-based interaction, multi-device rendering;

• The most aggressive competitors are exploiting internet oriented features for marketing purposes, however they currently provide only low-level features, which can be achieved with small effort. Only a few advanced SCADA products provide real value-added features. Possibly, current customer knowledge is not enough for appreciating the difference.

2.2.5 The proposed technological innovations

The following table shows the innovations proposed in this project to face the above described limitations.

Current limitation Proposed innovation

The access is limited to standalone use on the controlled machine or the local network.

Multifunctional architecture for standalone, local (LAN), fixed remote (Web), mobile remote (Wireless) access.

The user interface uses a proprietary program and is not based on standard technology (browser and mark-up languages).

Use of standard browser-based interfaces and mark-up and presentation technologies (HTML, XML, SVG, XML+Flash, ActiveX, Curl, etc.)

Software architecture where presentation and business logic are coupled

Adoption of multi-tier architectures with a separate presentation layer. Use of XML as a neutral format for data representation and user interface commands.

Limited interface configurability High level system for representing interface contents. Static and/or dynamic generation of

(17)

Mobility absence Use of an HMI-server able to produce interfaces suited for mobile access (e.g. GSM/SMS, GPRS or UMTS).

Personalization absence Explicit representation in the control logic

and in the profile user data; interface customization starting from such profile.

Adaptability absence Explicit representation in the control logic

and in user interaction context data; interface customization starting from such context. Table 2.1: Proposed innovations

Thanks to the technological solutions that will be adopted, the new devices will allow to change substantially many access modalities for managing complex system; in fact, it will be feasible to access the system from any remote place with the same interaction and control capabilities given by the local standalone access: in other words, the development of Poli-HMI project will surely lead to the simplification and decrease of costs in controlling and interacting with complex systems, and also to the complete users satisfaction.

2.3 The final innovation proposal

The evaluation of HMI-COMPANY current status and HMI market allows defining a product innovation strategy that aims at reaching (and passing over) the current technological status of competitors. The Politecnico di Milano proposal consists in a three-step solution that incrementally increases the features of HMI-COMPANY products in the direction of innovative, Web- based and mobile communications.

1. Web enabling the current product lines

As a first step, it is proposed to maintain the current run-time software, operating system and configurator. By introducing a few new components, it can be provided the user with advanced communication features. It is aimed at enabling Web functionalities, based on already available data, that are accessed by the new components. In particular, it is proposed to insert in the system a Web server, a database server (optional), and a (XML configurable) dynamic Web application. The result consists in the possibility of publishing on the Web the plant data and events log. It is also planned a minimal interaction with the field (some non-critical commands can be executed).

2. Remotization of the HMI interface

It is proposed to adopt an incremental solution, starting from the previous one: instead of publishing plant status using only traditional Web pages, it is introduced a rendering technology (SVG/Flash) which reproduces the panel interface in a simplified way, using the currently generated configuration files, possibly modified with a few variants. It is also planned some interaction with the field (some commands can be executed).

3. Architecture implementation shifting

For the long term solution the proposal consists in a Web-based architecture to be used both for local and remote access.

(18)

2.4 Project

goals

2.4.1 Hardware and software architecture

The following figure shows the overview architecture of the Poli-HMI solution proposed for this project:

LAN

Poli-HMI server

Presentation layer (mark-up and interface objects production)

Business layer (XML data elaboration, personalization, interfaces dynamic adaptation)

Data/field interface layer (user profile management, context and field data collection, commands to the field emission) Interface modelization system Interface model Internet Poli-HMI client (browser) Poli-HMI client (remote terminal) Poli-HMI client (PDA + micro browser)

HMI standalone Controlled environment

(plant, building, museum)

Figure 2.2: proposed architecture for the Poli-HMI solution

2.4.2 Research problems to be solved

The evolution towards the Poli-HMI concept and architecture shown in the previous paragraphs involves directly the HMI-COMPANY core business and therefore it must be managed with a proper technical and scientific support. For this reason, the project in discussion considers a strong involvement of the Politecnico di Milano as responsible for the scientific research supporting the development.

In particular, the Politecnico researchers have been involved in the following research area:

• analysis of the competitive scenario of the HMI products;

• monitoring of the evolution of the technologies that are important for building remote, multi-channel, mobile, personalized and adaptive applications;

• analysis of the requirements, the architecture specification and the user interfaces;

• definition of the software engineering and project management procedures suitable to the Poli-HMI systems development;

• definition of the modalities for analysing the applications performances;

(19)

3 SERVER-SIDE WEB TECHNOLOGIES FOR EMBEDDED

SYSTEMS

In order to create an architecture able to support the development of the Poli-HMI solution it has been important to analyse the technologies that can be implemented on embedded systems, considering their features, efficiency and performances.

The core of this study has been the server-side of the architecture, therefore in this chapter it is described only an analysis of technologies for creating server applications; furthermore, the focus has been restricted to server-side frameworks providing support for Web solutions. The technologies that have been considered are:

• CGI (Common Gateway Interface)

• ISAPI (Internet Server Application Program Interface)

• ASP (Active Server Pages)

• ASP.NET

• Web services

3.1 Analysis

context

Before starting with the description of server-side technologies it is important to define the context in which the study has been done, in particular it is significant to underline that it has been essentially used only the Windows CE Operating System; the reason for this choice can be found in the fact that, after a detailed evaluation of embedded operating systems, it has come out that only Windows CE and Linux offer the most complete solutions, resulting each one in a low cost and maximum flexibility combination. It has been preferred to analyse Linux and Windows CE in two different studies and in this document only the results concerning Windows CE are given. It must be also emphasized that, at the moment, some of the products of the HMI-COMPANY adopts Windows CE as operating system and this means that HMI-COMPANY has a high competence on this OS.

Windows CE is a good compromise between performances, offered functionalities and footprint size. In fact, in an embedded system, it is difficult to find solutions able to reach good performances on a wide range of functionalities without having an exceeding footprint. “Microsoft Windows CE 5.0 is an open, scalable, 32-bit operating system (OS) that integrates reliable, real time capabilities with advanced Windows technologies. Windows CE allows you to build a wide range of innovative, small footprint devices.” [w1]

It must be also mentioned that it is available a tool called Platform Builder for Microsoft Windows CE 5.0 that is a fully-integrated development environment (IDE) for building custom Windows CE OSs and components for embedded system devices.

3.1.1 Methodology

The adopted methodology has been determined by the specific needs of the Poli-HMI project; hence, the following conclusions strictly apply to this specific context.

The following sections analyse and evaluate the above listed technologies; the paragraph structure for each technology consists in:

• overview: it gives a general description of the technology;

• how it works: it explains the components and the processes involved in the execution of applications built using the technology;

(20)

• support: it gives a list of operating systems and/or Web servers supporting the technology;

• support on Windows CE: it considers the possibility to run on Windows CE applications built with the technology;

• requirements: it gives a list of the software requirements for running the technology;

• requirements on Windows CE: it considers the requirements applying to a possible Windows CE implementation;

• Input/Output capabilities: it evaluates the capacity of the technology to support Input/Output operations such as file, XML file and databases management;

• advantages: it lists the advantages in adopting the technology;

• drawbacks: it lists the disadvantages in adopting the technology;

• conclusions: it gives a final evaluation of the technology.

In the following paragraphs it is possible to find technologies evaluation according to their Input/Output capabilities. The libraries identified and tested have been only the ones considered to be a “standard way” for performing I/O functions. To determine if a library could be seen as a “standard way” or not, two aspects have been evaluated:

• the company that produces and supports the library: it makes sense to study and test software that is developed by a software company that is well-know in the computer applications world and that also offers other software products; an example is Microsoft’s products that have been used for this analysis;

• search on the Web of code samples for performing I/O functionalities: it can be considered to be an important parameter of evaluation, in fact the Internet community of programmers offers a wide range of code samples; usually these examples use the most standardized code. It must be said that the sources which the samples are downloaded from must be always checked, in fact it may be that sometimes they are not reliable.

More in general, one of the main aspects that has been considered is the need of robustness and commercial feasibility of the solutions: for example it does not make sense to try some libraries that are not standard or that are not supported by a proper development team; indeed, these technologies would be too risky for HMI-COMPANY, since all the future versions of HMI-COMPANY products would depend on not well supported software.

3.2 CGI

3.2.1 Overview

CGI stands for Common Gateway Interface, a standard for interfacing external applications with information servers, such as HTTP or Web servers. It simply may be intended as an “agreement” between HTTP server and such external applications about how to communicate. External applications may be scripts or programs: the difference is that scripts are lists of commands written in a scripting language (like PERL, TCL) which are compiled and executed at run-time, while programs are standalone compiled executable files written in traditional programming languages (like C, C++, VB, etc.): a CGI script or a program is a program that the Web server can invoke. Invocation can be provided with in input explicit (from a Web form) or implicit (from HTTP header) data.

(21)

Originally, CGI was invented by NCSA (National Center of Supercomputing Applications) for the NCSA HTTPd Web server in 1993, so it is a relatively old technology which has been gradually replaced by more powerful techniques. On the other hand, it is still used especially in old-generation applications which use separate CGI programs to generate dynamic Web content. The programming language PERL is well known as a language used for CGI, but one of the points of CGI is to be language-neutral: the Web server does not need to know anything about the language used for development, therefore it is possible to use every type of language and any operating system; it must be considered that scripting languages require a script interpreter plug-in installed in the Web server but they are easier to debug, modify, and maintain than a typical compiled program.

3.2.2 How it works

The way CGI works from the Web server point of view is that certain locations are defined to be served by a CGI program. Whenever a request to a matching URL is received, the corresponding program is called, with any data that the client has sent as input. Output from the program is collected by the Web server, augmented with appropriate headers, and sent back to the client. The following figures illustrate this process more in detail:

Figure 3.1: The GET request is sent by the client

(22)

Figure 3.3: The output of the script is sent to the Web server

Figure 3.4: The HTTP response is sent to the client

The Web server and the CGI programs communicate in four major ways: environment variables, command line, standard input and standard output. The first three ways are used to pass data from the client HTTP request (POST or GET) to the CGI program, while the last is used to return data to the client.

Environment variables allow to maintain and to pass information state between independent HTTP request (HTTP is a stateless protocol): they are set when the server executes the external program.

3.2.3 Requirements

As it is a long-time asserted standard, CGI is supported by any modern Web server; owning a CGI-enabled Web server is the only requirement needed to execute CGI scripts.

CGI scripts and programs may be directly requested from a simple HTML page, so it is not necessary to provide the Web server with scripting capabilities (like ASP, PHP, JSP, etc.).

3.2.4 Support

Despite it is a relatively old technology, developing CGI extensions is quite easy and there is a wide active developers community which supports it providing solutions to common and specific problems. Developing in CGI can be considered a “home-made” solution without additional costs beside simple time spent in building source code.

(23)

3.2.5 Advantages

Summarizing, it can be identified a list of advantages in implementing a CGI application:

• language-neutral: as it has been previously written CGI does not depend on the language used to build the program;

• architecture-independent: the CGI program is independent from the architecture it is installed on;

• open standard;

• no license/run-time cost: it is not a proprietary standard;

• process isolation: the program is independent from other processes, hence it depends only on its execution environment.

3.2.6 Drawbacks

As any old technology, there are some disadvantages in using CGI: main problems affect security and performances.

Since a CGI program is executable, it is basically the equivalent of letting the world run a program on a system, which is not particularly safe. Therefore, there are some security precautions that need to be implemented when using CGI programs. Typically these safety measures regard access permission to the directory where CGI scripts are located, so extra time to configure Web server is needed in order to protect it against not permitted executions. Although this, security cannot be fully guaranteed.

CGI was originally conceived to define a standard for communication between Web server and external applications, therefore lifecycle of CGI programs is quite resource-consuming: when the Web server receives a request which refers to a CGI program, it must create a new process in order to execute the program and, for passing to this application all the information that could be necessary in order to generate the response, it can only communicate by means of environment variables and standard input. The creation of a process for each request is time-consuming and remarkably engages the resources of the Web server, factor which limits the number of requests that the Web server can manage. A direct consequence is that programs cannot interact with the Web server or take advantage of its abilities as they take place in separate processes. As an example, a CGI script cannot write on the Web server log.

There is also an alternative technology, called FastCGI, which is more performing as it uses a single persistent process to execute the CGI program, but it does not contribute in any way to make more interactive the Web server and the external program.

3.2.7 Support on Windows CE

The Windows CE Web Server is implemented as an installable device driver, which is loaded at the start-up of the system; on this Web server there is no support for CGI applications and it is also reasonable to believe that it will not be supported even in the future.

3.2.8 Conclusions

CE Web server limitations do not allow the use of CGI technology. Anyway, other serious limitations of this technology (especially performances) would not have made its choice preferable as time requirements are very strict in the Poli-HMI project; indeed, frequent consecutive requests to Web server which make use of CGI programs, would be extremely resource-consuming as there is much overhead generated by processes that are activated each time a request is issued.

(24)

3.3 ISAPI

3.3.1 Introduction

ISAPI is the acronym of Internet Server Application Program Interface; this technology was initially introduced for running on the Microsoft Internet Information Web Server (IIS).

An ISAPI server extension is a DLL that can be loaded and called by an HTTP server. Internet server extensions, also known as Internet server applications (ISAs), are used to enhance the capabilities of an Internet Server API (ISAPI)-compliant server. An ISA is invoked in response to a browser request and provides similar functionalities to Common Gateway Interface (CGI) applications.

The goal of ISAPI is to enable programmers to develop applications faster than CGI programs, due to their tighter integration with the Web Server.

There are two types of ISAPI:

• Extensions: they are modules that are explicitly called by the client to perform some tasks; they run within the server and respond by means of it to the client;

• Filters: they are always active modules, registered at the server start-up for being activated in response to certain events. When the respective event happens, the Filter performs its task. The advantage of filters is that they are transparent to the invoked applications/pages.

Extensions are conceptually free-threaded version of CGI programs, while Filters conceptually sit between the HTTP Server and the HTTP Socket.

ISAPI applications can be used to enrich HTML pages and to provide dynamic data (like CGI), while ISAPI filters can be used to add new authentication schemes, support new encryption or compression methods, change the content based on the client or other conditions, or provide logging capabilities.

• Example of Extension:

a user fills in a form and clicks a submit button to send these data to the Web server; this invokes the ISAPI extension that stores the information in a database and builds the HTTP response to be sent back to the client.

• Example of Filter:

the client sends an HTTP request with the session ID; this request is intercepted by the authentication filter that checks the validity of the given ID. If the validation is refused, the filter notifies an error to the server that sends back to the client an HTTP error message.

Both server extensions and filters run in the process space of the Web server, providing an efficient way to extend the server capabilities.

ISAPI are implemented in C/C++ and Delphi. An ISAPI is substantially a program that implements some conventional function and compiled as a dynamic link library. It must be said that all the samples and tests made for this analysis have been developed only using C/C++.

(25)

As previously described, the main difference between ISAPI extensions and filters is the way they start. While the former are called explicitly by the client, the latter are called by the server when a certain event happens. These tasks are performed by two entry points that must be implemented:

• Filters:

o GetFilterVersion: when the server starts up, it collects all the DLLs by calling this

function, that provides version information and determines the desired notifications and delivery priority. ISAPI filter applications should register only for the events that are required. Every time the server processes one of the available events, it will call any filters that have registered for that event;

o HttpFilterProc: when the HttpFilterProc entry point is called, the filter performs a

switch on the NotificationType parameter to determine which action must be taken;

• Extensions:

o GetFilterVersion: it is executed the first time the extension is called. This function is

called only the first time there is a call to the ISAPI DLL, therefore it is useful to insert in it all the initialization operations;

o HttpExtensionProc: this function accepts only one parameter and contains the

code to handle the client request.

One of the fundamental structures for an ISAPI is EXTENSION_CONTROL_BLOCK: it is passed to the ISAPI from the server through the HttpExtensionProc call and it contains information and methods for responding to the request.

The use of this structure is showed in the following examples:

• methods and fields of this structure are used in the implementation of the ISAPI; for example it can be used to know the requested method:

if (!strcmp (pECB->lpszMethod,”GET”)) …

where pECB is a variable of EXTENSION_CONTROL_BLOCK type;

• to write the response to the client it may be used the method WriteClient: PECB->WriteClient(pECB->ConnID,”some text”,&dwLen,0);

where the used connection ID is retrieved by the block and dwLen is the size of the written string.

The process following to a client request is here summarized:

• a client requests the ISAPI execution via HTTP;

• the Web server receives the request and calls the ISAPI DLL;

• it is executed the HttpExtensionProc(…) function;

• the HttpExtensionProc(…) function creates the HTTP response;

• the Web server sends the response to the client.

ISAPI filters and extensions are widely supported, making their use convenient. In particular it is significant to say that 2.0 version of ISAPI Filters and Extensions is supported by the Microsoft IIS, the Zeus Web Server, while Apache 2.0 supports only ISAPI Extensions.

Regarding Windows CE, the Web server (HTTPD) implementation supports both filters and extensions but only as ‘in-process’.

(26)

3.3.4 Input/Output capabilities

This paragraph analyses the features offered by ISAPI for managing Input/Output operations. In particular, it has been considered explicitly only Windows CE as deploying environment. What must be underlined is that I/O features are not granted by ISAPI, but by the programming language used to develop the ISAPI libraries; considering that ISAPI applications can be developed using C/C++, this allows to support a wide range of functionalities. Therefore, the limitation depends from the embedded system on which the application should be deployed on, in fact not all the C/C++ libraries are available for being compiled on different processors (like ARM, x86) or used on different operating systems. For what concerns this study, it has been tried to identify some libraries and instructions supporting the development of I/O features on Windows CE.

In the following subparagraphs it can be found the analysis regarding file management, database access and XML parsing.

3.3.4.1 File management

It is possible to manage files with the standard C/C++ primitives (fopen, fprintf), in fact ISAPI applications are allowed (depending on the OS settings) to access the file system, reading and writing files.

3.3.4.2 Database management

It has been possible to identify two possible solutions for managing a database on Windows CE (both 5.0 and .NET version):

• SQLServerCE

• SQLite

The former is the Microsoft SQL Server 2000 Windows CE Edition that is the compact database provided by Microsoft for embedded systems. It allows to develop applications supporting the SQL syntax. Its engine exposes only an essential set of relational database features.

SQLite is a DBMS embedded system technology that is well compatible with ISAPI (and C in general). SQLite is a totally free technology that allows creating, managing and querying SQL 3 relational databases. This technology has been used in other projects for embedded systems and has the advantage to be Open Source and at the same time well supported by its developing team, in fact its library is continuously updated. SQLite supports almost entirely the SQL expressive power: all the syntax constructs are enabled except for writing on views, drop and alter columns, right and full outer join, grant and revoke of privileges. It supports also nested transactions and, partially, triggers. Sources are available and can be compiled as a static library and linked together with the ISAPI extension that, in this way, incorporates DB management features.

3.3.4.3 XML files management

ISAPI has been plugged with the standard Microsoft parser, MSXML (version 3.0) and all its features are supported. MSXML is available both in DOM (Document Object Model) and SAX (Simple API for XML) version.

A DOM parser creates a hierarchical data structure representing the XML document, which, after the parsing process, can be explored and used. SAX instead acts at parsing time

(27)

Considering how ISAPI technology will be used in the project, SAX seems to be more useful since it does not use main memory storage for the whole XML file. Indeed, memory occupation can be huge in the case of large documents manipulation with DOM parsing. SAX parser manages the document raising events related to the XML nodes: it warns for beginning and ending of elements and the document, but also for encountering PCDATA content. The controller of these warnings is a module called handler that must implement an interface called ISAXContentHandler; this interface defines all the possible events; the handler contains the code to manage the related event. The parser, when generates an event, gives information related to it. For example, if the event is “startElement”, it calls the respective function in the handler, giving information of that element: the URI, the tag name, the attributes names and values, etc.

Regarding the DOM parser, it is possible to instantiate an object that represents the whole XML tree that can be parsed and also modified using XML Path Language (XPath).

3.3.5 Requirements on Windows CE

To let an ISAPI DLL run, the image of Windows CE must contain the following modules:

• WebServer HTTPD

• DeviceManagement ISAPI Extension

• WebServer Administration ISAPI

For managing XML files, it must be also installed the Microsoft XML library (MSXML3), while for database management, it is required to have installed either SQL Server CE 2.0 or the compiled SQLite library.

3.3.6 Tests and results

An ISAPI extension has been developed to test the features described in this report, and invoked remotely on ARM4i board running WinCE 4.2. A test has been also performed on the HMI-COMPANY device, X86, revealing the correct behaviour of the ISAPI technology on WinCE.

All the previously described features (file, SQLServerCE, SQLite, SAX parsing, DOM parsing and writing) have been tested and the results are successful, in fact it has been possible to develop ISAPI extensions able to provide these I/O capabilities.

The performances of these utilities have been studied in another analysis inside the Poli-HMI project; from this study it has been possible to identify a ranking based on performances:

1. Files reader/writer (best performances) 2. SAX parser

3. DOM parser 4. SQLite

5. SQLServerCE (worst performances)

3.3.7 Advantages

As already written, initially the goal of ISAPI was to enable programmers to develop applications faster than CGI programs, through a tighter integration with the Web Server. Compared with CGI, ISAPI has some advantages:

• it is more efficient and lighter for what concerns processes management;

(28)

Other general advantages of using ISAPI are:

• it is a technology with high performances as it is C/C++ compiled code;

• it is a powerful technology, as with C/C++ code it is possible to implement a very wide range of functionalities;

• there is only one process and this means better performances;

• it maintains the state between different requests.

3.3.8 Drawbacks

Implementing ISAPI brings also some disadvantages:

• it is not possible to easily separate logic and presentation layers, in fact the HTML response is built on the same ISAPI that calls the business functions;

• high complexity in writing code, in fact:

o it is more complex and cost-demanding than a scripting language (as for the case of ASP pages);

o ISAPI DLLs are multi-threaded, therefore, during the development phase, it is required to follow rules for thread-safeness;

o ISAPI DLLs are ‘in-process’, therefore they are part of the server core; this means that security-safety considerations must be taken and also that ISAPI wrong access to the memory could bring down the entire Web server.

3.3.9 Conclusions

ISAPI is a convenient technology because it is widely supported; it is efficient because it is multi-threaded and powerful because it can be thought as a remote interface of a C/C++ application. It has been also proved to support all the main I/O functionalities.

3.4 ASP

3.4.1 Overview

Active Server Pages (ASP) offer the possibility to use in a single Web page normal HTML code and also scripted code; this allows the Web server to return to the browser dynamically generated and customized content.

ASP comes after CGI technology; it was released by Microsoft Corporation in 1996, to run on its Internet Information Server (IIS) and Personal Web Server (PWS). There have been other releases of ASP, in particular 2.0 and 3.0 versions. ASP has evolved in ASP.NET, so there are no new versions of ASP; in fact Microsoft is now developing on .NET platform. It is available also an application that offers support for ASP and that is not a Microsoft’s product; this application is Sun Java System Active Server Pages (formerly Chili!Soft ASP) software that allows organizations to deploy Active Server Pages (ASP)-based Web applications on a variety of Web servers and operating systems.

(29)

The following figure shows how the ASP technology proceeds:

Figure 3.5: ASP pages execution process

(Figure taken from ‘Introduction to Active Server Pages for New Programmers Tutorial’ – 2002 WestLake Internet Training)

The entire process of execution can be summarized as:

1. the Web client makes an HTTP Request asking for an ASP page;

2. the Web server receives the Request and finds on its directories the requested page; 3. ASP statements are executed by the ASP engine of the server that can also produce

HTML code that is inserted in the response; the ASP statements are removed. The output of this process is the HTTP Response that contains HTML code without any server-side scripting;

4. the Response is sent back to the Web client;

5. the client processes the HTML and client-side scripting contained in the Response and displays the content.

3.4.2.1 Examples of ASP scripting

Server-side scripting in ASP can be inserted inside an ASP file surrounded by the delimiters <% and %>. The code contained by these delimiters is executed by the ASP engine on the server and it can be written with any expressions, functions and operators valid for the chosen scripting language. There are two main scripting languages for ASP files: VBScript and JScript; the default one is the former.

In ASP there are some useful objects that can be used:

• Response: it can be used to send output to the user by means of the server;

• Request: it can be used to get information from the user;

• Server: it is particularly important and it is used to access properties and methods on the server. One of the most important methods the Server object offers is CreateObject that creates an instance of an object;

• Application and Session: they offer a context from which a page can collect information or functions. The Application context is related to the whole Web application while the Session context refers to a single user.

(30)

Windows CE includes an HTTPD WebServer that is able to execute ASP pages. This functionality is offered by both 4.2 and 5.0 version of Windows CE (but also by previous versions of Windows CE).

ASP has been one of the first technologies that allowed developing server-side scripting and was introduced by Microsoft in 1996. ASP has been continuously developed and now its successor is ASP.NET; this technology comes directly from ASP, hence the development of ASP has been dismissed by Microsoft that is going on only with the .NET framework. A direct consequence of this approach by Microsoft is that some ASP libraries are no more supported and updated.

Another aspect that must be considered is that the Windows CE implementation of ASP supports only a subset of the functionalities that are supported by the Microsoft standard implementation (Microsoft Internet Information Services) of ASP.

3.4.3.1 Limitations of Windows CE implementation of ASP

The Windows CE implementation of ASP supports only a subset of the functionalities that are supported by the IIS implementation of ASP. The following list shows the main functionalities that are not supported by Windows CE–based ASP (the following missing functionalities refer to both 5.0 and .NET version):

• state maintained between requests: this is the greatest difference between the IIS and Windows CE implementations of ASP. Windows CE does not provide support for the Session or Application objects and does not send the Session-ID cookie that is used on IIS. Therefore, there is no automatic technique for maintaining state or session;

• Global.asa file: Windows CE–based ASP does not search automatically for a file that is named Global.asa to obtain global settings. Initial settings or commonly used routines can be only included by using header files;

• automatic initialization or termination functions: script procedures may be named Application_OnStart, Application_OnEnd, Session_OnStart, or Session_OnEnd, although Windows CE–based ASP does not treat them differently from any other user-created procedure. Windows CE–based ASP does not call script procedures automatically on application initialization or termination, as in the case with IIS-based ASP.

3.4.3.2 List of Server Objects supported by Windows CE implementation of ASP and differences from the version supported by IIS

The following list shows the three built-in server objects that the Windows CE implementation of ASP supports.

• Request

• Response

• Server

Each of these objects provides a subset of the corresponding IIS implementation.

In particular, Server.CreateObject is an important function that lets create COM objects. It is not supported by Windows CE-based ASP, therefore the creation of COM objects must be made with another procedure as suggested by Microsoft.

Analysis and design of a server-side Web architecture for HMI Embedded Systems

POLITECNICO DI MILANO

Facoltà di Ingegneria dell’Informazione

POLO REGIONALE DI COMO

Corso di Laurea Specialistica in

Ingegneria Informatica

Analysis and design of a server-side Web

architecture for HMI Embedded Systems

Relatore: Prof. Fraternali Piero

Correlatore: Ing. Brambilla Marco

Tesi di laurea di: Arcara Luca

matr. 666528

Italian abstract

Traduzione del capitolo “Introduction”

Ringraziamenti

Table of Contents

1 INTRODUCTION

2 POLI-HMI PROJECT OVERVIEW

2.1 HMI-COMPANY

2.2 Project

Overview

LAN

Controlled

plant

HMI

User interface

Control logic

Interface with the field

2.3 The final innovation proposal

2.4 Project

goals

3

SERVER-SIDE WEB TECHNOLOGIES FOR EMBEDDED

SYSTEMS

3.1 Analysis

context

3.2 CGI

3.3 ISAPI

3.4 ASP