1. PROGRESS project: Internet-enabled monitoring and control of embedded systems (EES.5413)  Introduction Networked devices make their capabilities known through advertisement of services: service: provided functionality in terms of actions, (autonomous) responses and state changes of an object as well as the properties (both functional and non-functional) of sequences of these.  Examples of services A coffee machine: overall: make coffee actions & state: switch on/off; adjust taste; responses: inform on current status A protocol layer overall: layer function, e.g. reliable transmission actions & state: provided operations and internal state responses: call-backs  Access to service: (network) protocol or API Left: focus on protocols, protocol handling becomes part of application. Right: focus on transparency, hiding distribution.  Universal Plug ‘n Play Architecture for peer-to-peer connectivity of devices in the home environment Protocol: defined on IP (in fact: protocol container) API: free to develop Six aspects: Addressing: device’s IP address obtained through DHCP or Auto-IP Discovery and advertisement: the Simple Service Discovery Protocol (UDP multicast) Service description: in XML Control: the Simple Object Access Protocol Eventing: the General Event Notification Architecture Base Presentation: Web browser Controlling networked devices: two middleware architectures dr. ir. P.H.F.M. Verhoeven, T. M. Tran MTD, ir. P.J.F. Peters, dr. J.J. Lukkien  Experiments (JAVA implementation of UPnP-2) TVControl to control a television Video On Demand UPnP-enabled coffee machine – upgrade legacy device UPnP scales badly because of HTTP carrier API straightforward and Java codesize reasonably small Naming mechanism not useful in dynamic environments  CORBA Object oriented middleware architecture for development of distributed programs Six aspects: Addressing: based on TCP/IP, but wireless CORBA allows protocol specific addressing, like BlueTooth or InfraRed addressing Discovery and advertisement: services are registered at a central repository, like the CORBA naming service. Service description: location in the naming repository, object types and interface definitions Control: remote method invocation Eventing: through the event notification service or through callback actions Presentation: is client and service specific With the Remote User Interface protocol on top Control: based on subscribing to the service and the interface presented to the user. The user interprets the available actions Eventing: updates are send to the subscribed client Presentation: abstract user interface descriptions in XML  Experiments (on PDA) RUI client and server applications in Java Several RUI services to control applications Platforms: Linux, Windows, Symbian Transport: InfraRed, Serial, wLAN, Ethernet  Conclusion RUI useful trade-off client vs. server computation. Central naming registry reduces bandwidth usage, but introduces a point of failure. Code size overhead of CORBA is significantly more in comparison to UPnP. CORBA reuses connections for better performance.  References UPnP: http://www.upnp.org/ CORBA: http://www.omg.org/corba API (Control point, Device) SSDPSOAPGENA XML Parser UDPTCP IP HTTP (extension) Web server Layer 2 Layer 3 Layer 4 Layer 5 Control point or Device application Layer 1 Coffee Server Actuators Sensors Coffee machine Coffee Controller UPnP Proxy Control Control point Device TCP/IP GTP adaptation Transport layer IIOP GIOP GTP CORBA API TCP/IP GTP adaptation Transport layer IIOP GIOP GTP CORBA API RUI Protocol CORBA API RUI Protocol client server actions & results Class diagram for API Device Application DeviceService Action State Variable Allowed ValueRange 11..n call-back 11..q11..m Control point Application Discovery GUIControl CDeviceCService 11..p 11..m 1 1..n 11..p wireless CORBA normal CORBA Functionality provided as an API application API application API Functionality through specific protocols communication infrastructure application communication infrastructure service