Michael Lavender
B.Sc., University of Victoria, 2001
A Thesis Submitted in Partial Fulfillment of the Requirements for the Degree of
MASTERS
OFSCIENCE
in the Department of Computer Science
@
Michacl Lavender, 2004 University of VictoriaAll rights reserved. This thesis may not be reproduced i n whole or i n part by photocopy or other means, without the permission of the author.
Supervisor: Dr. J. Jahnke
ABSTRACT
It is predicted t,hat smart embedded devices will be the new c0nnectivit.y wave on the
Internet. New technology and infrastructure will need t o be developed to facilitate this revolution. Smart embedded devices can play two distinct roles on the Internet; consumers of information and services, and providers. Consumers are already com- monplace with the advent of networkable PDAs and web-enabled cell phones, but providers put forth a greater challenge. Embedded devices, unlike web servers, have very limit,ed resources, including bandwidth, memory and non-volatile storage.
Developing t,hese web based embedded systems can be a daunting t,ask for software engineers. This is due to the many concerns which need to be addressed, such as
embedded code development, communication protocols, interoperability standards integration, and user interface development. Depending on the application, such a system could be required to service anywhere from one t,o thousmds of users.
The objective of this thesis is to research architectural alternatives and solut'ions to meet this challenge. This research is carried out in tight collaboration with an industrial partner (Intec Automation Inc.). Intec has developed microcommander; a component-based, embedded development, monitoring and control solution. micro- Commander is designed for one-to-one interact,ion with a target microcont~roller and does not provide thin client accessibility.
The plan is to ext,end microcommander funct,ionality to provide access t'o mult.iple target microcontrollers for mult,iple simultaneous users via a secure web-browser based interface. To attain this goal, I have designed and evaluated multiple solutions with different architectures before finally focusing in on a promising solution which uses a three-t'ier a.rchitecture.
The proposed solution is built using microCommander t.echnology, XML Web Services and ASP.NET. The middle tier (mGateway) serves as a liaison between
the embedded device and the end user. mGateway translates Web Service calls into binary messages to and from the embedded device and uses a data cache for efficiency. Browser-based user interface development is made simple by using out-of-the-box ASP.NET Web controls and either ASP.NET Web Matrix or Visual Studio .NET for construction.
Abstract ii
Table of Contents v
List of Figures xi
List of Tables xiii
Acknowledgement xiv Dedication xv 1 Introduction 1 1.1 Background . . . . . . . . . . . .
.
. . . . . . . . 1 1.2 Motivation . . . . . . . . . . . . . . . . . . 2 1.3 G o a l . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 Document Structure . . . . . . . . . . . . . . . . 3 2 Related Work 5 2.1 Pervasive Computing . . . . . . . . . . . . . . . . . 52.2 Embedded Component Based Software Development . . . . .
.
. . . 62.2.1 LabView
.
. . . . . . . . . . . . . . . . . . . 72.3 Internet Monitoring and Control . . . . . . . 7
2.3.1 Bringing XI0 to the Web . . . . . . . . . . . . . . . . . 8
2.4 Net-cent,ric embedded solut.ions . . . . . . . . . . . . . . 8
Table of Contents vi . . . 2.4.2 Jini 9 2.4.3 emware . . . 11 3 Requirements 1 2 3.1 Background . . . 12 3.1.1 Home Automa.tion . . . 12 3.1.2 microcommander . . . 14 3.1.3 Observations . . . 18 3.2 Hardware Requirements . . . 20 3.2.1 Microprocessor . . . 20 3.2.2 Volatile Storage . . . 21 3.2.3 Non-Volatile Storage . . . 21 3.2.4 Networking . . . 21 3.2.5 Input/Output . . . 23 3.3 Software Requiremen& . . . 23
3.3.1 Multiple User Access . . . 24
. . . 3.3.2 Quality of Service 24 3.3.3 Thin Client Accessibility . . . 25
3.3.4 Third Party GUI Development . . . 25
3.3.5 Standards Based API . . . 26
3.3.6 Secure Access . . . 26
4 Architecture Overview 27 4.1 Embedded Web Server . . . 27
4.1.1 Details . . . 27
. . . 4.1.1.1 Application Cont'rol Logic 28 4.1.1.2 HTTP . . . 28
. . .
4.1.1.3 microcommander 28
. . .
. . .
4.1.2.1 benefit,^
4.1.2.2 Drawbacks . . .
4.2 Two-Tier Direct Connection . . .
4.2.1 Details . . .
4.2.1.1 Application Control Logic . . . . . . 4.2.1.2 TCP/IP 4.2.1.3 microCommander . . . 4.2.2 Observations . . . . . . 4.2.2.1 benefit.^ . . . 4.2.2.2 Drawbacks
4.3 Three-Tier with Web Services . . .
4.3.1 Details . . .
4.3.1.1 Application Control Logic . . .
4.3.1.2 TCP/IP . . . 4.3.1.3 microCommander . . . 4.3.2 Observations . . . 4.3.2.1 benefit.^ . . . 4.3.2.2 Drawbacks . . . 4.4 Conclusions . . .
5 Interactive Models for Embedded Components
5.1 Embedded Web Server . . .
5.1.1 Component Model . . .
5.1.2 Component Composition and Life Cycle . . .
5.2 Two-Tier Direct Connection . . .
5.2.1 Component Model . . .
5.2.2 Component Composition and Life Cycle . . .
Table of Contents viii
. . .
5.3.1 Component Model 47
. . .
5.3.2 Component Composition and Life Cycle 47
6 System Design 5 1 . . . 6.1 microCommander 51 . . . 6.1.1 Components 52 . . . 6.1.1.1 Component Design 52 . . . 6.1.2 Framework 54 . . . 6.1.2.1 System component.^ 55 . . . 6.1.2.2 mTarget 55 . . . 6.1.2.3 mvisual 56 . . . 6.1.3 Communication 57 . . . 6.2 mGateway 58 . . . 6.2.1 Configuration Adapter 58 . . .
6.2.2 Component Type Adapter 59
. . . 6.2.3 System Description 60 . . . 6.2.4 mGateway Core 61 . . . 6.2.4.1 Interface 61 . . .
6.2.4.2 Communicat. ion Mana.ger 63
. . . 6.2.4.3 Controller connections 64 . . . 6.2.4.4 ComponentTypeDefinitions 65 . . . 6.2.4.5 Data Caching 67 . . . 6.3 mviewer 67 . . .
6.3.1 ASP.NET Web Controls 68
. . .
6.3.1.1 Design Time 69
. . .
6.3.1.2 Run Time 73
7 Evaluation and Conclusion 75
. . .
. . .
7.1.1 Two Tier . ActiveX 75
. . .
7.1.1.1 Compatibility Issues 76
. . .
7.1.1.2 End User Trust 76
. . .
7.1.1.3 Multiple User Support; 77
. . .
7.1.1.4 User Interface Development 77
. . .
7.1.2 Three Tier - Web Services 77
. . .
7.1.2.1 Deployment Overhead 78
. . .
7.1.2.2 Usability and Responsiveness 78
. . .
7.1 . 2.3 User 1nt.erface development 79
. . . 7.1 . 2.4 Quality of Service 79 7.2 Conclusions . . . 79 8 Future Work 82 . . . 8.1 Security 82 . . .
8.1.1 Web Service Security 82
. . . 8.1.2 microcommander Security 83 . . . 8.2 0pt.imization 83 . . . 8.2.1 Data Cache 83 . . . 8.2.2 Streaming Data 84 . . . 8.2.3 Multi-component Requests 84 . . . 8.2.4 Quality of Service 85 . . .
8.3 User Interface Development 85
. . .
8.3.1 Richer ConOrol Library 85
. . .
8.3.2 Semi-Automat. ed User Interface Evolution 86
References 87
Appendix A Example System Description 90
Table of Contents x
Figure 2.1 microSynergy Editor . . . 10
Figure 3.1 Architecture of a home automation system . . . 13
Figure 3.2 microcommander Architecture . . . 15
Figure 3.3 microcommander component logic view . . . 16
Figure 3.4 microcommander operator interface view . . . 17
Figure 3.5 Highly Customized Home Automation Interface . . . 19
Figure 3.6 microcommander Architecture (mserver) . . . 22
Figure 4.1 Embedded Web Server . . . 29
Figure 4.2 Two Tier Architecture . . . 33
Figure 4.3 Three Tier Architecture . . . 37
Figure 5.1 Embedded Web Server Component Model . . . 41
Figure 5.2 Two-Tier Component Model . . . 44
Figure 5.3 Three-Tier Component Model . . . 48
Figure 6.1 Figure 6.2 Figure 6.3 Figure 6.4 Figure 6.5 Figure 6.6 Figure 6.7 Figure 6.8 microcommander Distribution . . . 52 Example CCB Layout . . . 54
mGateway Deployment Model . . . 58
Configuration Adapt. er Class Model . . . 59
Component Type Adapter Class Model . . . 60
System Description Class Model . . . 61
mGateway Core Class Model . . . 62
List of Figures xii
Figure 6.9 mViewer Design Time . . . . . . 72 Figure 6.10 mViewer Run Time . . . . . . . . . . . . . . . . . 74
List of
Tables
. . .
Table 4.1 Architecture Comparison Matrix 39
. . . Table 5.1 Embedded Web Server Component Life Cycle 42
. . .
Table 5.2 Two-Tier Component Life Cycle 46
. . .
Table 5.3 Three-Tier Component Life Cycle 50
. . .
Table 6.1 Example Component Types 53
. . .
Table 6.2 PID Controller Meta-data 55
. . .
xiv
Acknowledgement
Dedication
Chapter
1
Introduction
The Internet has become the central network for a large percentage of computer to computer communication. In the past ten years we have seen t,he number of personal computers on t.he Internet increase massively. It is predicted that the next wave of the Internet will be smart embedded devices. There are two categories of Internet enabled smart embedded devices, those which are consumers of information and services, and those which are providers of information and services. The consumers are already commonplace, for example web-enabled cell phones and Personal Digital Assist,ants (PDAs). The providers can be things like automated home controllers, industrial controllers, or even a refrigerator. These two categories are not mutually exclusive, as many of the providers also consume other services, but less commonly do consumers provide services.
This new connectivity wave brings a need for new technology and infrastructure. Embedded devices, unlike their counterpart personal computers (PCs), have some different and more challenging requirements for Internet connectivit,~.
1.1
Background
Smart embedded devices, also known as embedded systems, are in many of the prod- ucts and services that. we use today, including but not limited t,o appliances, auto- mobiles, kiosks, and office buildings. Accessing information and services from these
embedded systems via the world wide web (WWW) should be as easy as accessing any web site or web based service.
Currently much of the information from these systems needs to be extracted man- ually and posted t,o the WWW, which is cumbersome, error prone, costly, and often out of date or inaccurate. Over the past ten years technology in the embedded system world has accelerated, producing smaller, more powerful mini-computers. Many of these mini-computers (microcontrollers) now have the capability to connect directly to the Internet via a high-speed ethernet network. This ability ca.n be exploited to provide people with seamless, and secure access t o their devices.
1.2
Motivation
Though microcontrollers are becoming more powerful, there are still many limitations, including lack of hard disk storage, small amounts of volatile RAM, and the massive heterogeneity of software, kernels and operating systems. This presents a challenge for accessing these devices with everyday PCs and P C software. Many of the popular interoperability and compatibility st,andards for P C software have big footprints and require a large amount of runtime resources. Even though there are currently efforts to provide "skinny" versions of these standards and frameworks, there is still a large gap especially when considering the lower end of these embedded devices.
1.3
Goal
The objective of this thesis is to research archit,ectural alternatives and solutions such that, t.he above ment,ioned challenges can be met. This research is carried out in tight collaborat,ion with an industrial partner (Intec Automation Inc.). Intec has developed microcommander; a component-based, embedded development,, monitoring and con- trol soIut,ion. microcommander is designed for one t,o one interaction wit.h a t.arget
1 . Introduction 3
microcontroller and does not provide thin client accessibility.
The plan is to extend microcommander functionality t o provide access to a tar- get microcontroller for multiple simultaneous users via a secure web-browser based interface. To att.ain Ohis goal, I have designed and evaluated multiple solutions with unique architectures before finally focusing in on a promising solution which uses a three-tier architecture.
The proposed solution is built using microcommander technology, XML Web Services and ASP.NET. The middle tier (mGateway) serves as a liaison between the embedded device and the end user. mGateway translates Web Service calls into binary messages to and from t'he embedded device and uses a data cache for efficiency. Browser-based user interface development is made simple by using out-of-the-box ASPNET Web controls and either ASP.NET Web Matrix or Visual Studio .NET for construct,ion.
1.4
Document Structure
Chapter 2 This chapt,er will discuss an application scenario, introduce the micro- Commander t,ool, and present the requirements for this project.
Chapter 3 Introduces relat,ed work, including Internet monitoring and control, per- vasive computing, and network-centric embedded technologies.
Chapter 4 present.^, Analyzes and compases three possible aschitectures for this project.
Chapter 5 Conveys t,he underlying component models, composition paradigms, and life cycle for each of the three architectures.
Chapter 6 Lays out, t,he detailed design for the three tier architecture which was impIement,ed as part of this research.
Chapter
2
Related Work
2.1
Pervasive Computing
Computers amre becoming less apparent in our everyday lives. No longer must a person sit down at a traditional computer workstation or terminal to perform their everyday tasks such as email, word processing, etc. The field of pervasive computing, views the world with smart inOeroperable computing devices which are deployed in a ubiquitous manner[l]. A computing device can be defined as anything from a mainframe computer to a typical PC workstation to smart embedded devices such as cell phones, web appliances, and even wearable comput,ers. These computing devices all participate in a smart net,work which can adapt as devices drop in and out,. Ubiquity implies that a person should not. lse limit,ed to t,he location or the time for which they have access to this sma.rt network.
A lot of work has been done in the pervasive computing field. Xerox PARC, a research hotbed in the eight,ies and early ninet'ies, may have inspired much of this work with the development of their Active Badge system [2]. The system was used to t'rack t.he location of people within an office building by having them wear an elec- tronic badge that communicated t,o sensors placed t'hroughout the building. More recently pervasive computing has been taking adva,ntage of t.echnologies which are already commonplace such as PDAs and sma,rt phones. These hand held devices are much more powerful than their c~unt~erpart badges from the Active Badge sys-
tem. The Pervasive Servers[3] project examines the use of PDAs as mobile perva- sive servers which communicate with stationary embedded servers via HTTP. The COWSPOTS[4] project also uses PDAS to communicate with a central server over
HTTP (Web Services) and receive context sensitive information. Majurski [5] on the other hand, describes a syst,em targeted t,oward small embedded devices (8, 16, and
32 bit) which uses a special software framework based on the Fourth Language. A pervasive computing world in the pure sense is still far from "here". It is the opinion of some[6] t,hat t,he success of pervasive computing is dependent on how visible computing devices are. People will not truly embrace the technology until they can't tell they are using it.
2.2
Embedded Component Based Software Devel-
opment
Component based software development (CBSD) employs a building block approach where developers assemble off-the-shelf components to form a unique application. Perhaps one of the most referenced definitions of a software component comes from Szyperski [7]
A software component is a unit of composition with contractually specified interfaces and explicit cont,ext dependencies only. A software component'
can be deployed independent,ly and is subject to composition by third parties.
In the embedded domain there is some activity with respect to component based
development.. Urt.ing et a1[8] are working on the SEESCOA project (Software Engi- neering for Embedded Systems, using a Component Oriented Approach), which uses the SEESCOA composer tool to engineer embedded applications using pre fabricated component,^. Attenttion to non-functional requirement's such as memory footprint and
2. Related Work 7
timing constraints, is given to components in the SEESCOA system. There is also the PECOS[9] (Pervasive Component Systems) project which uses a langauge called CoCo (Component Composition Language) to define embedded applications. PECOS was a collaborative effort between industrial and academic partners which concluded in Sept. 2002.
2.2.1
LabView
Possibly one of the most notable commercial products for component based develop- ment is LabView from National Instruments (NI)[10]. LabView was first launched in 1986, fathered by Jeff Kodosky a co-founder of NI, and has since taken off to huge market success[ll]. LabView uses a visual language which allows components to be connect'ed together and logic to be created. LabView also provides user interface development and runtime frameworks. Originally developed for lab hardware, it has since expanded to include many types of computing devices including Programmable Logic Controllers (PLCs) and microcontrollers.
2.3
Internet Monitoring and Control
Remote monitoring and control is not new. Up until the advent of Internet many syst'ems were developed with proprietary networks. These networks often required special hardware and software which was not included as part of a standard PC. Now that t,he Internet has become ubiquitous it is desirable to piggyback on this infrastructure for a number of rea,sons. First, the communication protocol is proven, st,able, and has many implementations. Second, almost every new PC comes equipped wit,h the required hardware and basic software t,o participate on the Int,ernet. Thirdly, due to t,he massive popularity, t,he hardware components required t,o connect to the Internet have become very inexpensive and feasible for attaching t'o virtually any computing device.
Work is currently taking place in various domains with respect to Internet moni- toring and control. Weaver[l2] outlines some issues and solutions for monitoring and control of a Factory over the Internet while ot,her domains include HVAC[13], home automation[l4], and even robotics[l5].
2.3.1
Bringing X10
to the Web
XI0 is a networking protocol for power lines found in the standard home. Signals are sent from a controller to one or more modules plugged into a wall or light socket. These signals instruct the module to either turn "on" or "off' (and "bright'en" or "dim" in the case they are controlling a lamp). A controller (there are different types) can receive commands from a wireless remote or a serial (RS232) connection to a local P C or other computing device. In the case the controller is receiving commands from a local computing device automation can be achieved. A home computer feeding commands to the XI0 controller also opens up the door t,o Internet connectivity.
There has been a lot of work done with respect. to controlling X10 devices over the Internet. There are numerous commercial solutions[l6] such as PanTilt PRO, Webview and ActiveHome. There are also a large va,riety of hobby and open source
project,^ using everything from Java to ActiveX to Linux.
2.4
Net-centric embedded solutions
In the past decade many of us have become familiar with the term business t o business (B2B) ecommerce. In the past couple of years some new terms have been appearing on the radar screen, specifically B2M and M2M meaning business to machine and machine to machine respectively. B2M and M2M are due to the massively increasing amount of embedded devices in the world and t,he huge demand for the interoperability among them. For example, a person should be able t o use their PDA to pay for their cab ride or even turn the furnace on at their winter cabin. The following sections
2. Related Work 9
describe some of the technologies which are aimed at meeting the B2M and M2M challenge.
microSynergy[l7] is an ongoing research project at the University of Victoria (UVic) in coIlaboration with Intec Automation Inc. The project was initiated to enable target to target networking capabilities of component based embedded systems. The project has since evolved to include the reuse and upgrade of legacy code into new component based and networked embedded systems[l8]. microsynergy piggybacks on technology from Intec Automat,ion for developing component based embedded systems.
microsynergy consists of two main parts; the microsynergy runtime engine, and the microsynergy editor. The runtime engine is a microcontroller based program which acts as a network router transferring data packets to and from microcontrollers connected to a Local Component Network (LCN). The microsynergy editor is how the user defines the logic used in the runtime engine. The editor uses an SDL like visual language to define how signals are routed. Figure 2.1 is a screen shot of the microsynergy editor.
2.4.2 Jini
Jini is a technology first developed by Sun Microsystems to facilitate network-centric computing syst,ems which are adaptive t o change[l9]. Jini is an extension of Sun's Java technology and takes advantage of t'he Java Remot,e Method Invocation (RMI) syst'em. The idea is to make all network devices plug and play so that users are no longer plagued with installing software, and drivers manually. For, example Waldo[20] suggests a network printer installation being as simple as just plugging it in, and if you want to uninstall it, just unplug it.
2. Related Work 11
due to the Java virtual machine which must be present on any device running Java or Jini code. The Java language provides a subset for embedded devices, Java 2 Micro Edition (J2ME)) intended to cut down the amount of required resources to run Java programs. White[21] introduces J2ME including, the target market and computing devices.
emware is an industry leader in remote device management solutions[22]. emware is responsible for the Embedded Micro Internetworking Technology (EMIT) which is a framework including software and development tools for adding connectivity to embedded devices. EMIT developer kits include software which generates embedded C code to run on embedded devices as well as PC based libraries written in Java and C++ for developing user interfaces which can irit'eract with embedded devices.
Another technology provided by emware is called DeviceView. DeviceView is a web-based service for remot,e monitoring and cont'rol of embedded devices. The service can be hosted by third parties or in the corporate enterprise.
Requirements
Embedded systems exist in many different application domains. Though these do- mains do share some common requirements, each one also has its own unique char- acteristics. First I will describe the type of domain for which this research has been focused, give an overview of microCommander and how it is used with respect to that domain, and then present my observations of that solution. Next I will present the requirements with respect to those observations with the goal of creating an enhanced solution.
3.1
Background
3.1.1
Home Automation
The potential for the home automation market is hi .utomation in t'he home can consist of environmental control, lighting, security systems, irrigation, ent,ertain- ment, and more. The benefits that these systems can bring to their owners include lower energy costs, security, peace of mind, more free time, and increased conve- nience with everyday tasks. Home aut,omation systems are often controlled by a central microcontrolIerl which c~mmunicat~es with one or more smart devices such as
'The benefits of using a microcontroller over a regu1a.r P C include less power consumption, smaller size, better reliability. PCs are multi-purpose machines which run operating systems which require regular rebooting, and are vulnerable to viruses and trojans
3. Requirements Local Interfaces pane remote control Central Control
'
n
I
Remote Interfaces .AI
Smart Embedded Devices
Home thermostat entertainment
lamps
lights
--
PC laptop PDA phone
Figure 3.1. Architecture of a home automation system Qarage
door opener
thermostats, light switches, digital video cameras, electric motors, and more. The central controller is responsible for retrieving data from the smart devices and issuing instructions back to those devices based on its pre-programmed logic. In addition to executing logic, the central controller is responsible for interaction with an end user who can locally and remotely monitor and control the devices in their home. Local interfaces t o this controller are usually in the form of a strategically placed control panel, short range wireless remote control(s), and/or a connection to the home workstation/PC. Remote interfaces operate over the Internet via either a work- station, laptop, and/or mobile web-enabled devices such as PDAs or cell phones. The microcontroller does not require these interfaces to control the devices, once the microcontroller is programmed and running it will work autonomously whether a user is connected or not. Figure 3.1 portrays th~e architecture of the described home automation syst.em.
Developing a home automation system requires both hardware and software. The hardware can be purchased off-the-shelf from vendors like X10 and Shell. The soft- ware that runs on the hardware (smart embedded devices) is often pre-programmed to do a very simple task and can be used as is. The software for the central con- troller, on the other hand, requires domain specific logic. The central controller is usually programmed in a low level programming language such as C or Assembler. This embedded microcontroller software is difficult t o develop and may require in- timate knowledge of the low level hardware specifics. The software for t,he central controller also requires a communication interface for talking to the embedded devices and the end user. Communication t o the smart embedded devices can be achieved via dedicated network cables using standardized protocols like RS485, Ethernet, and Controller Area Network (CAN), or can piggy back on existing infrastructure such as power lines. The graphical user interface may consist of an LCD screen connected direct.1~ to the controller and/or a P C based user interface, which is connected to the controller via the standardized communication cables. The software for the graphical user interface(GU1) on the P C can be developed using advanced GUI development tools and programming languages, which is contrary to the tools often used for em- bedded software development.
Systems like these are often developed on a one by one basis wit,h very little reuse. microcommander is a tool developed by Intec Automation Inc. which takes a visual, component oriented approach t o embedded development and allows the creation and use of operator GUIs for monitoring and control purposes.
The microcommander tool is comprised of an embedded kernel, mTarget, and a visual Windows based user interface, m Visual. mVisual runs on any Windows based desktop PC while mTarget. is compatible with a specific subset of microcont,roller platforms. mVisual communicates to mTarget via A TCP/IP connection and can therefore be
L ocket (LAN or WAN)
r
- A \ /
Figure 3.2. micro Commander Architecture
used on a Local Area Network (LAN) or the Internet. Figure 3.2 shows the high level
architecture of microcommander. The Real World bubble represents devices that are controlled via the microcontroller inputs and outputs, for example, a sprinkler system.
With mVisual the user can create logic and build user interfaces for their micro- controller. Logic is created by instantiating pre-programmed components which are included as part of the mTarget kernel. This is realized by the user, in mvisual, by dragging and dropping an icon from a toolbar. Instantiated components can be configured using a property sheet dialog which contains various parameters, including the ability to link to other component instances. Components are linked together to
control the flow of data through the controller. Data flow is initiated via I 0 events or the internal timer. Special system components can hook into these I 0 events and the internal timers and execute jobs on other components. A job is an action which is taken on a component instance with an optional parameter, such as Set Temperature to 25C where Set Temperature is the act1011 and 25C is the parameter. All the com- ponent instances together form an application which can be saved to flash memory on the microcontroller or as file on the host PC running mvisual.
The home automation scenario can be developed using microcommander. Figure 3.3 is a screen shot of mVisual in the component logic view with an open property di- alog The open property dialog represents an On/O# Controller component instance acting as a thermostat. The On/Off Controller component maintains a desired set-
" ~ o o r n Terngmtlire Convecter Temp Senfor, Frnwd 1DK Celcur. 1
Figure 3.3. microCommander component logic view
point given an analog source and a digital output2. The preprogrammed logic will turn the digital output on when the source's value drops below the setpoint and turn it off when the source's values goes above the setpoint. Additional properties include
inverted logic, a deadband, and a mode setting.
In addition to the component logic, mVisual provides monitoring and control via a
visual control panel. A user can drag and drop ncons from a toolbar to create virtual instrumentation for control and monitoring. Each virtual instrument is connected to an underlying component instance from which it retrieves and sets values based on mouse and/or keyboard user input. Visual controls can be overlayed on a raster wallpaper image to provide context for the end user/operator. In addition to the
main control panel embedded in the mVisual window. panels/windows can be created
t o hold additional visual coiitrols and may be nested. Nested control panels are
3. Requirements 17
Figure 3.4. microCommander operator interface view
represented on there respective parent panel with a short-cut icon which when double- clicked will show the child panel. The visual control panel in mVisual for the home automation scenario could look like Figure 3.4 The main control panel (obscured by the foreground windows) contains a floor plan bitmap and a set of strategically placed
sub control panels representative of the respective areas in the house. Three of the sub panels are open including the master bedroom, garage and security system. The master bedroom has controls for the thermostat m d lighting as well as a temperature indicator, the garage has controls for the door and lighting, and the security system shows two live web camera feeds for the front and back doors respectively.
3.1.3
Observations
Although microCommander makes the task of software and operator GUI develop- ment for embedded systems much easier, there are some shortcomings that need to be addressed for this scenario.
Single User Access This system only allows one user to be logged into the central controller at one time. A typical scenario including a local PC and one or more remote a.ccess PCs/laptops could cause a frustrating situation. For example an occupant of the home logs in with the home workstation and then the doorbell rings, some time after anot,her occupant tries to access the home from their workplace and they are denied access. Add one or two more occupants into
the scenario and the situation becomes rnuch worse. Single user access is a limit'ation of microcommander t,hat exists for a couple of reasons. First, the target microcontroller has very limited resources compared to the web servers of today and can simply not afford multiple simultaneous connections and still carry on doing its control logic in a timely fashion. Second, mVisual is used as a development tool as well as a monitoring and control t,ool. Simultaneous development of contxol logic presents many problems t,hat are not an issue with simultaneous control and m~nit~oring.
Rich Client Only The described scena.rio requires the user to install mVisual on every computer for which they would like access to their home. This is prob- lematic for a few reasons. A home owner may want to access their home on a computer for which they have no administration rights, preventing the in- stallation of third party programs. A home owner may want to access their home from a non-windows P C or a mobile device. mVisual can only be run on Windows desktop operating systems and ha,s a much t,oo large foot,print to run on a mobile device.
3. Requirements 19
A k t k -
-"--
Statistics Legend
Sndh Res.dsace Date Aprrl 16, 2084 ~ m m Sta%+dtcs 3
3218 I\iBai&y Br
i;ma 70 45 ~ O A ~ V I
a
a * - E R C ~ R B ~ JWbowbunch, Sask
EF-9U7 fiiarm State& OK
FLRST FLOOR
Figure 3.5.
Highly
Customized Home Automation InterfacemVisual is not as aesthetically pleasing, efficient. and interactive as a home owner might like. mVisual is a multi-function tool and simply cannot provide the type of flexible interface that many third party tools will allow. The home owner is limited t o creating graphical user interfaces with a very limited set of virtual instruments and a raster wallpaper. Figure 3.5 is an example of a
much richer, scalable interface for a home automation system which would not be possible to develop with mvisual.
Closed System Interoperability is not an option with microcommander. For ex- ample, it is not possible to integrate microcommander with already developed user interfaces. This type of integration would be ideal in the home automation
rity syst,em or web cameras, in place. The user should be able to develop a one stop web site for accessing and controlling their home.
Security microcommander security is limited to a simple username/password au- thenticat,ion scheme. Messages between mVisual and mTarget are in binary form, but are not encrypted. For the home automation scenario authentication would typically be the biggest concern, though privacy and non-repudiation may also be required.
3.2
Hardware Requirements
Everyday new microcont~rollers are being released which are faster, smaller, have a larger quantity of volatile and non-volatile memory, support more peripheral de- vices, consume less power, and cost less money than their predecessors. The most common peripherals, Electronically Erasable Programable Read Only Memory (EEP-
R O M ) ~ , Universal Asynchronous Receiver-Transmitter (UART) for serial communi- cations, and Ethernet. for TCP/IP communications. The other major feature of a microcontroller is the Input and Output (10). The I 0 is what really sets microcon- trollers apart from regular computers. Microcontrollers use I 0 to control equipment and talk to other devices.
The hardware requirements for this research are driven entirely by microcomman- der. The intention is not to modify the microcommander kernel or components, but to work on t'op of them to provide more accessibility to them. The following sections will outline the t,ype of ha.rdware features required by microcommander.
3.2.1 Microprocessor
Microcontrollers, like a PC, are built around a microprocessor. There are many dif- ferent, microprocessors which are designed specifically for microcont~rollers. These
3. Requirements 21 processors are optimized for size, power consumption, and I 0 peripherals. The mi- crocontroller platforms of concern in this research are limited t,o those supported by microCommander. These include, but are not limited to Intec Automation's Mite (Mororola HCl6), Z-World's RCM and BL2XXX product lines (Rabbit2000), Tech- nologic System's TS product line (Intel/AMD x86), and JKMicrosystemls LogicFlex and uFlasTCP (Intel x86).
3.2.2
Volatile Storage
The minimum amount of RAM required to run microCommander is sixty four kilo- bytes(KB). This is enough room for the microcommander kernel variables and up to at least one hundred user instmtiated components. Many microcontrollers, including those mentioned in the previous section, are equipped with at least t,his amount of RAM.
3.2.3
Non-Volatile Storage
Microcommander uses non-volatile memory for storing the mTa.rget embedded code, and up t o four user applications. One of the user applications stored in non-volatile memory can be configured to automatically load on power up. This is useful when power outage is a concern, since a running microCommander application st'ores com- ponent instances in volatile RAM. The required amount of non-volatile storage is at least one hundred and twenty eight kilobytes, sixty four of which is used for the kernel and component code and the ot,her half is used for saved user applications.
3.2.4
Networking
TCP/IP Networking is a key requirement for an interactive web based embedded syst,em. Although there are many microcont,rollers without TCP/IP capability, their market share seems to be decreasing. Microcontrollers without TCP/IP capabilities
L
RS232 Serial Socket (LAN or WAN)
r
\ / \ /
J
-
[Digital &Analog 10 )
\ . J
Figure 3.6. microCommander Architecture (mserver)
can still be accessible over the Internet via a TCP/IP gateway. Such a TCP/IP gateway is relatively easy to develop for a PC or another embedded platform. One such gateway comes prepackaged with microcommander (mserver) and runs on any Windows PC. Figure 3.6 depicts the architecture of microcommander using mServer as a TCP/IP gateway. The gateway acts as a proxy between the Internet and the microcontroller without TCP/IP. The communication between the gateway and the microcontroller can be one of many communication protocols such as RS232, blue- tooth, or CAN-Bus. A microcontroller with Ethernet and TCP/IP can be connected directly to the Internet with a gIobal IP address or behind a router/firewall with Network Address Translation (NAT). Port forwarding or Virtual Private Network- ing (VPN) can be used to access a microcontroller connected to a LAN behind a router/firewall.
3. Requirements 23
Microcontrollers need Input/Output (10) to interact with the outside world. I 0
can come in the form of digital and analog. microcommander has a specific set of components called Hardware Agents which provide access t o the I 0 pin(s) on the microcontroller. The I 0 used in this research is confined by the hardware agents available in microCommander. Currently microcommander supports digital inputs and outputs, analog inputs and outputs, and pulse width modulation output (PWM).
There are also variations of these agents which allow more sophisticated control of the hardware such as pulse trains, which use digital outputs and a timer t o generate a quasi-analog signal. The availability of these I 0 types is dependent on the target platform.
3.3 Software Requirements
The software required for the home automation scenario is often a dist.ributed software system. The software runs in different locations on different platforms and is expected to function as a single cohesive entity. Dealing with this distributed nature can make software development more complex. microcommander is designed to cut down this complexity by providing a generic communication and component framework as an off-the-shelf tool set. This tool set, t,hough effective with some a,pplications, has limitat'ions. These limitations include only one user may be logged into a target microcontroller at a time, the same tool (mvisual) that is used for developing control logic and operator GUIs is also used as the operator interface, mVisual must be
installed on a Windows PC, and there is no third party extensibility model. These limitations ma,ke t.he home automation scenario less desirable to the home owner.
The following sections describe t,he software requirements for overcoming t,he afore- ment'ioned limitations wit.h the microcommander solution.
3.3.1
Multiple User Access
Multiple user access is applicable to many application domains, and home automation is no exception. This is simply due to the fact that many homes are inhabited by more than one person. Each person in the home should be able to log in, monitor the status of, and possibly control devices without the limitation that they are the only
one currently logged in. We require that our solution provides seamless access to the embedded system regardless of simultaneous users. Also simult.aneous uses should not affect the microcontroller's other obligations such as controlling an automated system. For example the microcontroller should not miss an alarm event from the heater because it was too busy transmitting temperature dat'a to one hundred connected users. Multiple simultaneous users only refers to monitoring and control and not application development.
3.3.2
Quality of Service
As embedded syst'ems are heterogeneous so are t'he applications for which they are
needed, which leads to different quality of service requirement.^ by t'he client. The client requires the ability to specify a quality of service. The quality of service will
depend on the application on the embedded system, and the client.'^ context. By context, I mean who the client is, and what t'ype of st,akes do they hold in the system. For example, a client that is monitoring the temperature outside their house strictly for convenience need only a very low quality of service in the sense that the temperature does not change quickly and t.he actual value is only for curiosity. On the other hand, a gardener that is monitoring the temperature of a greenhouse needs a much higher quality of service in the sense that if the temperature changes only slightly the impact could be very large and action may need to be taken immediately. It is a requirement that t,he client can request a quality of service from the ser- vice provider based on t.he following parameters; currency, latency, priority/cont.ext'.
3. Requirements 25
Currency refers to the currency of the data passed to the client, this will most likely be measured with respect to the maximum amount of time it could be since this data was updated from the actual system. Latency refers to the maximum amount of time it will take the service provider to fulfil a control request. Priority/Context refers to who the service is for, and for what reason it is being used. The service provider need only provide a time limited guarantee of service which will most likely equal the
maximum time that the provider can foresee spending to provide the service based on historical statistics, server power, and/or administration parameters.
3.3.3
Thin Client Accessibility
In order t o allow access from non-Windows PCs and mobile devices, a web browser interface is required. Web browsers are developed on fairly strict specifications and can be found on virtually any modern operating system. Mobile devices also offer compact versions of web browsers. Most often web browsers are installed as part of the operating system. We require that our end user interface is accessible from a web browser on any computer.
3.3.4
Third Party GUI Development
The GUI development provided by mVisual is seamless but aesthetically a.nd func- tionally inflexible. As opposed to reinventing a GUI development tool within mvisual, it is a requirement to allow GUIs to be developed using third party tools. Mature GUI development tools often provide a broad set of features as well as an exten- sibility framework. It is also a requirement that a set of microcommander plug- ins/components be developed for a couple of st'rategically selected target tools to aid in the development process. These plug-ins/components will make connecting the visualization to the data (underlying components) as seamless as it is in mvisual.
and availability, and market popularity/acceptance.
3.3.5
Standards Based
API
An open application programmer Interface (API) implemented with a standards based protocol is required. This will enable developers to integrate other user interfaces and applications with systems running microComma,nder. This API will also be used in the third party GUI development tool and therefore may limit the selection tools which can be used and the plug-ins which can be developed.
3.3.6
Secure Access
Unauthorized access to an embedded system can have very bad implications, espe- cially in the case that the embedded system is controlling a physical device. If the embedded system is accessible via the WWW, the threat of unauthorized access is very real. Unauthorized access can come in the form of the intruder actually con- trolling a device, or, simply pirating information that he/she is not sanct,ioned to have. To prevent such attacks, the system will be required to authenticate users and encrypt information being sent across the network. Beyond authentication and en- cryption the system will aJso need to keep a log of activity that can accurat.ely depict who did what and when. The log can then be used to track usage and to hold wrong doers accountable for their actions.
Chapter
4
Architecture Overview
The objective of this chapter is to present, analyze and compare different architectures
for connecting embedded systems t o the WWW.
4.1
Embedded Web Server
Most of the web pages on the WWW are served by high-end computers called servers. These servers are similar to desktop PCs except they often have more hard drive space, more powerful (and multiple) CPUs, high bandwidth network adapters, data redundancy, and operating systems and applications optimized for severing many remote users. Since microcontrollers are in fact mini-computers with many similar
components to that of a desktop PC, it is feasible to host web pages directly on the microcontroller.
4.1.1
Details
Hosting web pages directly on the microcontroller requires an embedded HTTP server. In addition to the HTTP server the microcontroller still needs to do its everyday
control tasks. The application control logic and HTTP server need to share the resources of t'he microcontroller including the CPU, RAM, and non-volat.ile storage. In addition, the HTTP server and application control logic need t'o communicate wit'h each other in order t o exchange commands and data to and from the user via HTML.
The communication can come in the form of shaxed memory, function calls, or Inter Process Communication (IPC) if using an Real Time Operating System (RTOS)'.
4.1.1.1 Application Control Logic
Application control logic on a microcontroller is what makes the system work. It is the algorithms and data structures that provide the domain and context specific functionality. Most often this consists of reading inputs, processing the data, and initiating outputs. The logic runs as an independent process and will continue to run regardless of a user interface. The application control logic is most often programmed by a domain expert.
4.1.1.2 HTTP
Contrary t,o a PC, microcontrollers often do not come with an operating system which includes a web server implementation. Though there are RTOSes which do support off-the-shelf HTTP servers, they are often expensive and only targeted toward certain high end microcontrollers (QNX, VxWorks). This means that a web based system not running an RTOS is required to implement the HTTP protocol alongside the application cont,rol logic. There are many examples of HTTP implementations in many programming languages and the ~pecificat~ion exists on the World Wide Web Consortium (W3C) web site.
In the previous sections I have described in general the makeup of an embedded system with a web server. Now I will describe such a system, but as an enhancement to microCommander[24]. Figure 4.1 depicts t,he embedded web server archit,ecture
'Web servers typica.11~ have multitasking operating systems and can therefore run the web server software ( H T T P server) as a.n independent process in the background and communicate with appli- cations via Inter Process Communication (IPC), an RTOS typically provides a similar mechanism
4.
Architecture Overview 29Figure 4.1. Embedded Web Server
with microcommander used as the application logic development tool. mTarget has been modified to include an HTTP server. mTdisual can still connect to mTarget via a socket connection and applications can be built and tested using the mVisual tool. When an application is completed a user may point their web browser at the microcontroller's IP address and inspect and set the data values of their components via HTML pages.
4.1.2
Observations
This architecture is a workable solution for a web-based embedded system and has the following benefits and drawbacks.
4.1.2.1 Benefits
Thin client This architecture allows thin client accessibility. The monitoring and control interface is exposed as HTML pages and requires nothing more than a web browser to view.
4.1.2.2 Drawbacks
Microcontroller CPU Usage The CPU must service both requests from the HTTP server and t,he application cont.ro1 logic. All the CPU time could be consumed servicing requests from the HTTP server in a multi user situation. Putting limitations on the HTTP server CPU requirements to free up time for critical
embedded operations could make for an unresponsive User Interface.
Microcontroller Non-volatile Storage Requirements HTML pages and the HTTP protocol must be included on the microcontroller. A microcontroller without a filesystem must embed the HTML in binary form. The more complex a user in- terface required (pictures, javascript,) the more space required leaving less room for application control logic code.
User Interface Development The HTiVIL and the embedded code are closely cou- pled in this type of system. Using a third party web development tool is most likely out of the question a s the information may need to be compiled into the code it.self.
4.2
Two-Tier Direct Connection
The two-t,ier architechre takes much of t'he resource requirements out of the microcon- troller and places them on t'he client's computer. Most often the two tier architecture is implemented by using a rich client. A rich client is a program that runs code on tlhe client's computer, in contrast to a thin client which only renders the interface Do
4.
Architecture Overview 31the client's computer and runs all code on the server. There are also hybrid solutions which can run rich clients as if they were thin clients by downloading the code at the
last minute through a web-browser. Technologies such as ActiveX controls and Java Applets are examples of this hybrid solution. Since the rich client code is running on the client computer the user interface will run more smoothly and can use native drawing routines.
4.2.1
Details
The embedded part of the two tier architecture is similar t,o that of the embedded web server. Instead of having and embedded B T T P server, the microcontroller in this inst,ance implements only a T C P server. A T C P server is a layer below an HTTP server and only exchanges data as opposed to display information like HTML. The client tier is responsible for all display information and custom T C P communication code. The code for the client can be a stand alone application or a component. If the client code is programmed as a component t'he code can be downloaded just in time and does not have to be installed (explicitly) on t,he client computer. This variant of the two tier architecture requires a web server t'o host t,he binary code and any other display information. Figure 4.2 shows the two t,ier archit,ecture with the client code
downloaded just in time from a web server.
4.2.1.1 Application Control Logic
The application control logic in this example is no different than that of the embedded web server.
The microcont~roller implement,^ a simple T C P server. The server needs Do do nothing more than accept connections and send and receive messages. The messages sent
and received can be any binary (or Text) format for which both the client and the microcontroller agree on. This type of communication tends to be faster than that of HTTP as the messages are smaller and the protocol simpler.
microcommander uses a two Oier architect'ure. mVisual is a rich client which connects to mTarget directly. mVisual is used to create a,nd maintain the application logic on the microcontroller and to provide as a user interface builder and run-time engine. As an enhancement to microcommander our research team has decoupled the micro- Commander user interface runtime engine and ported it to an Act,iveX component[25]. With this implement'ation it is now possible to create application control logic within mVisual and t.hen monitor and control the system from a web browser. The solution implemented did not include the user interface design abilities of mvisual, but instead provided a simple API t o the ActiveX component, which enables a developer to create any type of user int'erface they want. In our implementation we creat,ed an SVG user interface and used JavaScript to communicate wit.h the ActiveX component.
4.2.2
0
bservat ions
This architecture is a workable solut.ion for a web-based embedded system and has the following benefits and drawbacks.
4.2.2.1 Benefits
Rich Interface The interface for a rich client is often smoother and fa.ster. This can
provide the user with a more enjoyable user experience.
Third Party User Interface Development In the microcommander example the
user interface runtime engine exposes a design t,ime API which t,hen allows de- velopers t,o hook into with t,heir own inter€ace design tools.
4. Architecture Overview 33
4.2.2.2 Drawbacks
Client Compatibility Though the rich client is nice, it requires code t o run on the client machine which requires the client machine t o be able t o run that code. This code can be written and even compiled to platform agnostic format, but then will require a run-time engine which may or may not exist for the desired platform. If the runtime engine does exist, it may not be installed which can require the user to download and install it, which requires administrative rights on the client computer.
Client Security Code must be trusted by the user in order to run on their computer. Though code can run in a sandbox on the client computer the code for this application requires access to the network. Most web browser's will post large warning messages, before the code is downloaded, which can be intimidating to
users and result in the code being rejected by the user.
Microcontroller CPU Usage (multi-user) Though not as severe as the HTTP Server on the microcontroller a T C P server still requires resources. The re- sources required scale linearly with the number of simultaneous connections.
4.3
Three-Tier with Web Services
A three tier architecture addresses many of the requirements presented in the previous chapter. The middle tier can t,ake the resource burden from the microcontroller and all the security issues from the end user. With Web Service Technology, the middle tier can also provide an open Interface to not just one computer, but to the world.
The three tiers consist of the microcontroller, a communicat,ion gateway (mGateway), and the client,.
4.
Architecture Overview 354.3.1
Details
The microcontroller (embedded) part of the three tier architecture is identical to that of the two tier architecture with application control logic running alongside a TCP server. The middle tier is similar to that of the client tier in the two tier architecture. All the communication code runs on this tier. The middle tier also keeps a cache of all data retrieved from the microcontroller such that is can be reused when multiple clients request data. The interface to the middle tier is implemented as a Web Service and can therefore be (potentially) accessed universally. Web service access can be invoked implicitly behind an ASP.NET web page via a user action or a meta refresh. A stand alone or componentized rich client can also be used t o access the web service.
4.3.1.1 Application Control Logic
The application control logic in this example is no different than t.hat of the previous two architectures.
The T C P server on the embedded platform is no different than that of the two t,ier architecture.
microcommander can be enhanced t,o use the t,hree tier architechre. mVisual is used from a Client P C t o connect to the microcontroller and define and maintain t,he ap- plication control logic. With another t.001 (ASP.NET Web Matrix) the user interface is developed by using ASP.NET server controls and/or cust,om server controls2. The user interface is then deployed as a web site on a web server. The client then accesses 'In our implementation of the three tier architecture we provide a sma,ll set of custom server controls including one d a t a source control for communicating with the mGateway web service
the web site like any other. Each request to the server results in a request t.o the web service and may or may not result in a request to the microcontroller3. Figure 4.3 shows the three tier architecture with mVisual used as the application logic develop- ment tool. The cIient tier is made up of the combination of the client PC and the Web server which hosts the user interface web pages and executes the server code to access the mGateway service.
4.3.2
Observations
This architecture is a workable solution for a web-based embedded system and has the following benefits and drawbacks.
4.3.2.1 Benefits
Thin client Like the embedded web server this architecture requires the client only a web browser to run. This opens up the door t o all kinds of devices including cell phones, PDAs, thin client laptops, and more.
Target Resource Usage Constant Unlike the previous two architectures, the three tier architecture is scalable based on the number of end users. Since t,here is only one connection between the microcontroller and the outside world, the re- source usage on the microcontroller will stay (somewhat) constant/predicatble with respect to the number of end users (cIients/operators).
Large Number of Potential End Users The mGateway server can potentially be an extremely high powered4 computer capable of serving many connection simultaneously. The data cache prevents too many requests from going to t'he microcontroller.
3The middle tier maintains a cache of data from the microcontroller and may be able to simply return the cached data depending on the clients currency requirements
4.
Architecture Overview 37 Monitor & Control (Client) , - - X C \-
Internet Socket 2 ' - P - / HTTP (ASP.NET-
Internet FTP JThird Party User Interface Development Like the two tier architecture, a third party tool can be used t o develop the user interface. This enables very cus- tomized interfaces and a separation of concerns with respect t o the application control logic. Development tool plug-ins or add-ons can also be used to enhance the user interface development.
4.3.2.2 Drawbacks
Deployment and Maintenance The middle tier (mGateway) requires a web server with the ability to host web services and the security rights to make direct socket connections. The user interface must also be hosted on a web server (this can be the same server). Web server space can be rented from various places on the Internet for a monthly fee. Alternatively a personal or corporate web server can be locally maintained.
Overhead Since every request in this archit.ect,ure can go through as many as four machines and as few as t,hree machines t,he overhead does have a,n effect on the speed in which data can be retrieved and sent.
Many Failure Points By having three tiers, the points for which failure can happen are increased. The web server hosting the pages could go down, mGateway could go down, or even the client PC. In any of these cases access t.o the embedded system is restricted until all are functioning. Some of these problems can be resolved with redundancy on the server side.
4.4
Conclusions
Which architecture Do choose will be dependent on the requirements for the specific project. Table 4.1 compares each of the three archit.ectures (vertical columns) with respect t,o five characteristics (horizont,al columns). The embedded web server archi- tect'ure is good for projects with high-end microcontrollers and short time to market.
4.
Architecture Overview 39Table 4.1. Architecture Cornwarison Matrix Characteristic
Thin Client Target Resources Third Party UID
Deployment Overhead
1
LowI
ModerateI
HighEmbedded Web Server Yes
High/Extreme
Development Overhead
I
ModerateThe major issue with this architecture is scalability. A two tier architecture is good for lower end microcontroI1ers (including those without ethernet) and accessibility
mainly from PCs. The major issue with this architecture is client software require- ments. Finally the three tier architecture is best for lower end microcontrollers, and anytime, any device, anywhere accessibility. The major issue with this architecture is the need for a web server and the skills to implement a user interface.
I I I No Two Tier No Moderate/High I I I Moderate Three Tier Yes Moderate Yes High Yes
Interactive Models
for
Embedded
Components
The purpose of this chapter is to present the underlying component models for the architectures discussed in Chapter 4 (Architecture Overview). The key concept to these component models is to facilitate interaction with an end user from a web browser. For this to be realized, the visual operator interface component composition paradigm used within mVisual will not suffice. In particular the operator interface for a component instance is required to be browser compatible. This modified require- ment a,ffects the way that operator interfaces ca.n be composed. It is not the desire of the Intec team or this research project t o reinvent web page composition tools from wit,hin the mVisual tool. Further more, it may be more efficient to leverage off existing technologies and development tools. We have investigated various avenues for applying this paradigm to our web based architectures.
The following three sections will discuss each architecture's component model and the component composition and life cycle. The composition and life cycle for each architechre will focus on the operator interface facette. The component composition and life cycle with resepect to the embedded application logic is identical for all architectures and will remain wiOhin the mVisual development. tool paradigm.
