Patent Application
20080294667
The invention relates to a method of communication for data transfer to an electronic microdevice according to the preamble of claim 1, to a computer program product, and to a data structure product.
At present, increasing demand is felt for including and integrating the largest possible number of electronic devices into a common communications network, so that access to the data of the devices thus connected, as well as remote control of such devices becomes possible. It will be advantageous to retain for future use the familiar technologies, surfaces, and interfaces already introduced. While it is relatively easy to include devices having marked computing power and the corresponding memory and use widely known protocols such as TCP/IP or HTTP, the system requirements associated with such protocols constitute a problem for electronic microdevices having low computing power, scarce memory, and low rates of data transfer.
Yet, including such devices into local networks or into global networks such as the Internet, would provide users with basically worldwide access to such devices, e.g., for remote control of domestic appliances from a vacation resort A need exists, therefore, to include even microcontroller-based microdevices into existing communications systems, and to be able to operate them like a kind of webserver, despite their memory limitations and despite the low rates of data transfer. It should then become possible to connect these microdevices with display devices such as a PC, mobile devices, webpanel PC, media TV, etc., so that a generic browser existing in these display devices could provide a display of the user interface of the device, such as a graphical user interface (GUI), thus making a remote operation of the microdevice possible. It should not be required to install any device-specific software in the display devices, in order to secure a universal facility for inclusion, and compatible microdevices would be recognized automatically.
Networking technology for electronic microdevices should then wherever possible have the following characteristics:
Purely by way of example, some generic microdevices and their applications will be listed in the following.
Methods are known in the prior art which certainly can be used to operate microdevices via PC. This is even true for particularly small devices such as sports watches, sphygmomanometers, multimeters, etc. They have in common, however, that device-specific software must be installed for each of the devices on each of the display devices. When a newer device model has been acquired, in most cases a new software installation is required. Similarly, when a new display device (PC) has been acquired, then for each of the devices, the software must be reinstalled. This software installation usually is done via a CD delivered with the device, or via an online page with download, and requires a number of steps. Apart from the applications software proper, device-specific drivers (that is, hidden software) must also be installed in many cases. This requirement is a deterring obstacle for large part of the PC users, and is demanding even for well versed users.
Particularly for devices having a small microcontroller (<100 kB memory, 8 bit computing power or lower), it looks as if these requirements for an integration without the installation of device-specific software components could not be satisfied, for the following reasons in particular:
It is the aim of the present invention to provide a method for improved or simplified communication with electronic microdevices.
It is a further aim to enable inclusion of such microdevices into communications systems without the need for any device-specific adaptation on the user side.
It is a further aim to enable remote control of microdevices via communications networks such as the Internet or via LAN or WLAN.
According to the invention, these aims are attained by the subject matter of claim 1, they are also attained or solutions developed by the characterizing features of the dependent claims.
The invention relates to a method of communication for data links with an electronic microdevice. According to the invention, a computing unit is included as middleware between the microdevice and the computer used to realize the user interface. This middleware acts as an intermediate layer, handles requests directed to the microdevice, and where applicable adapts data to be transferred in this context, by changing or supplementing them. This middleware then acts as the interface between browser and microdevice, in such a way that seen from the browser, a virtual functional unit has been created that has a higher level of performance than the microdevice.
The script-based browser uses data input from so-called “scripts” and from files, and files containing data to be used are retrieved while working through the scripts. These two elements thus embody content, structure, and style of the user interface. The scripts are text-based at least in part, and can be read by people in a simple text editor. The approach according to the invention consists in providing the settings and data that are specific to the microdevice, by the microdevice via the middleware, and procuring the retrieval via a file designation assigned to the microdevice, such as a file name or commented entry. Communication commonly starts by a query concerning a so-called default file such as index.html. The browser thus accesses (such) a file that is transported via the middleware or is provided by the middleware, which assumes all additional functions required to secure interoperability. This holds true more particularly for the compression or decompression of files, for supplementing data to be transferred to the browser, and for handling communication with the microdevice.
The functions and files or libraries specific to the microdevice thus are provided by the middleware acting in the background, and able to access preinstalled, fixed or static sets of data as well as external resources provided dynamically via communications systems. Naturally, various other variants including, e.g., a periodic local download of data resources updated and provided via the Internet or via a LAN, are possible.
Commonly, networks are characterized in terms of the OSI model where the individual functions of a data communications link are divided into seven different categories or layers. The well-known Hypertext Transfer Protocol (HTTP) then refers to the application-oriented three top layers. In layers below, TCP and IP are found. The user or software application proper is located as the application layer above the uppermost protocol layer No. 7. In the following, the specific common case will be considered where HTTP is used as the protocol for the transfer of (HTML) files and where these. (HTML) files are represented in a browser. Within the HTML file, further files may then be requested that are needed for display (e.g., image files) or script processing (e.g., a JavaScript file or Flash file). Ordinarily, in a HTML file only the uppermost layer of the HTTP protocol may be addressed (requesting a file by file name), but not the layers beneath. Access to layers beneath is not possible in HTML, while in JavaScript additional input (i.e., additional lines of code) is needed and may lead to errors. In the approach according to the invention, the microdevice preferably is limited to making a file request by file name, in order to save resources, so that for the purposes of caching, the unique file identification should preferably be contained in the file name. This understanding is relevant for the concept of caching according to the invention that is presented below.
It is made possible by the invention, in particular, to link microdevices that are particularly small and have data transfer rates and memories distinctly smaller than those found in PCs and mobile phones, with display devices and more particularly with PCs, mobile telephones (particularly the so-called “smart phones”), mobile devices having a browser with Ajax and/or Flash capability, and television sets (possibly provided or connected with a so-called set-top box that can establish a connection with the Internet or even with the microdevices). It is also made possible by this invention that those microdevices not normally having an Internet connection, may comfortably communicate with the user via display devices. It is an essential part of the invention, finally, to provide each of these devices with a user interface via a browser that is present as a standard, and that has Ajax capability, that is, will understand JavaScript as well as “asynchronous JavaScript and XML” (=Ajax) in addition to HTML. The XMLHttp request enables an asynchronous reloading (that is, reloading occurring in the background) of data such as the files illustrated below that contain data in an xml oder json format, and subsequent updating at the intended place in the browser without the need for a reloading of the full page (as in HTML).
The technology presented here is particularly powerful in the context of microdevices having particularly small chips, e.g., 8 bit chips having 100 kB of memory or less. In such microcontrollers, the so-called web server technology is certainly known, but as a rule it merely provides static representations offering relatively small operating comfort, as they rely on HTML exclusively. The prior art does not realize a dynamic check of data present in the microdevice that occurs in the background, or their representation in the browser. According to the invention, it will be quite possible instead of the Hypertext Markup Language (HTML), to implement even in such small microcontrollers Ajax script language that has since become dominant in the web design field, while limitations to be expected on account of limited memory and low data transfer rates, and last not least even on account of limited computing power, will now be overcome.
It becomes possible in this way to link small microprocessors with a browser, and where applicable with the Internet as well, without having to realize a full TCPIAP protocol on this small processor. This approach would actually be advantageous where the processor has a higher computing power. Thus, it is quite common to use a 32-bit processor for TCP/IP applications. Larger processors cannot be used, however, in applications where device dimensions, price, and power consumption are dominant considerations, and the smallest possible microcontrollers are needed.
According to the invention, moreover, a specific syntax is suggested for server-side includes, that is, a syntax for a dynamic inclusion of values of variables into script pages, and at the same time a syntax for the assignment of variables is specified that enables an early development of (Ajax or HTML) scripts and their continued testing on a simulation web server specifically adapted. In addition, a very simple and transparent interface between device developer and Ajax script designer (web designer) is made possible. In this way project execution becomes simpler and more transparent, project duration is shortened, and success of the project more likely.
According to the invention, the following data structures and principles of data transfer are used, either individually or cumulatively in the context of device communication:
Modifications of this solution that are made in accordance with the invention can be implemented by one skilled in the art, for other protocols and system requirements as well, the basic principle of relieving the microdevice in matters of protocol syntax, computing work, and data transfer requirements being retained. The protocol may be defined more particularly as a genuine subset of HTTP. This can be achieved by inserting in each case the HTTP line “content length:[length]” in front of the HTTP content, rather than attaching EOF at the end.
Many connections come about via a USB adapter. The middleware could be present in such a USB adapter with memory function, so that it is available automatically without any prior installation (“software cable”). This USB adapter then serves in a double function: it stores the middleware (USB memory stick) and it also contains a signal adapter, e.g., from USB to a serial data cable (RS232, RS485, RS422 or the like), from USB to ZigBee (ZigBee coordinator function), from USB to UWB, etc.
The invention offers particular advantages in a technical constellation such as that pictured above, but it is not limited to it. Thus, it can be applied without limitations to the connection of all possible small devices.
The invention, and more particularly the easy-to-handle caching mechanism, can further be used as well out of the context of microdevices, in the Internet and in web applications, to take care of reliable caching of files uniquely identified by their file names, that is, of a caching of files and more particularly of common library files independently of browsers and URL, as well as to prevent the reloading of such files.
Such a function can be made a fixed part of the browser (also as a plugin, for example), so that the middleware need not be started separately. It can also be solidly integrated into the operating system or started automatically when starting the operating system.
The method according to the invention will be described or explained in greater detail, purely by way of example in view of the embodiments represented schematically in the drawings. Individually shown are in
The middleware 4 provides a file that is specific to microdevice 1, the device assignment occurring via the file designation such as the file name or via the URL. The middleware 4 may be realized as an independent unit having its own hardware, or it may be implemented as software on another platform that is used together with other applications. In this case it has access to a memory 5 that is arranged in the platform or in the hardware of middleware 4 itself or is provided externally via a data link, or both. For the middleware, uniformity and suitability for a number of applications is the aim here, that is, a design that is universal rather than specific to the given microdevice 1, so that according to the invention, more particularly, a single middleware 4 will enable communications with a multitude of different microdevices. Middleware 4 and its functions are specifically kept open for being used with different microdevices 1, each having different memory capabilities and computing rates, all the way down to single-chip microprocessors, and with different types of linkage such as Bluetooth, ZigBee, WiFi, DECT, NFC, RFID, etc. This means that we are talking here about generic software to be installed just once (PC, mobile phone, set-top box), which after its first installation may fetch library updates and/or protocol updates from a central location in the Internet and will not require renewed installation when connecting a new microdevice.
For its part, middleware 4 is connected with the microdevice 1 via a second communications link ZK having a lower data transfer rate than the first communications link, more particularly, lower than 3 Mbps or even as low as 9600 bps, while the computing power and memory of microdevice 1 are smaller than the computing power and memory of the middleware 4, the memory in particular being smaller than 100 kB or at most 32 kB.
The design of the second communications link ZK is the limiting factor, more particularly for communications protocols designed for the use of universal, powerful systems configurations, a situation that holds primarily for solutions based on TCP/IP or HTTP.
The keeping and providing of data required for microdevice 1 are handled via the middleware 4, which also defines the interfaces to the display device 2 and to the browser, so that the browser sees this configuration as a virtual microdevice 1a having higher capabilities.
Data assigned to the microdevice are transferred to display device 2 via middleware 4 when the components cooperate, the data transfer from the microdevice 1 to the middleware 4 being synchronous or asynchronous with the establishment of the communications link. The browser merely retrieves from the script the file that is specific to the microdevice 1. The data to be transferred are adapted by the middleware 4 in the background in such a way that the file is provided as the file that is specific to the microdevice, while for the display device 2, this specific file is recognized from the file designation as applying to microdevice 1, so that a representation by the script-based browser becomes possible and the middleware 4 as middleware for display device 2 defines the functional interface to microdevice 1. Apart from retrieving a single file that could for instance contain the data of microdevice 1 that are loaded down asynchronously via the slow second communications link, more complicated data structures may also be provided, but are embodied in a single file on the browser side, more particularly by establishing a web server data structure consisting of only one default file and one zipped file, the latter containing script files, so that the middleware 4 when responding to an inquiry of display device 1 to the microdevice, performs an automatic retrieval and unzips the zipped file.
The function of middleware 4, to unzip file content and have the content ready as separate files for corresponding browser inquiries, may extend to individual files (such as “device.zip”, “devauto.zip”), to entire groups of files (e.g., all files with the extension zip), or to files that can be recognized from a corresponding header line (e.g., with “content encoding:gzip” in the header). This function can be performed for one or several files automatically when a new microdevice 1 is connected and recognized, without waiting for a corresponding browser request (for instance, “device.zip” is requested independently by the middleware 4 from microdevice 1 after this has been connected, and when present, the content is unzipped and cached). Since an identification is not present in the file “device.zip”, this procedure will have to be carried out whenever microdevice 4 is reconnected.
If now files containing a unique identification are found in a file such as device.zip that has been unzipped automatically by middleware 4, then these files will—as soon as requested—be stored in a permanent intermediate memory for uniquely identified files. If ONLY such uniquely identified files are present in the unzipped file, then the request and the automatic unzipping may be omitted, and microdevice 1 will be connected more rapidly. Such a mechanism can be implemented purely script-based in JavaScript: at first a script that should be loaded and is uniquely designated by its file name, and that is present, e.g., in device.zip, is requested. If not found, then device.zip will be requested separately, its content automatically unpacked, and sent to intermediate storage, so that the above file may be requested once more, now successfully. If found, the loading of device.zip can be omitted, etc.
While they are adapted, the data to be transferred may also be supplemented, in which case the middle ware 4 may retrieve the supplements from a storage unit 5. Also, the middleware 4 may simplify the data transfer protocol for microdevice 1, particularly by reducing it to a subset of the hypertext transfer protocol, and/or convert the data to be transferred, more particularly by data compression or data decompression.
File designations that may be used are the file names or a URL, while a hash value may also be included into the file name or into a corresponding URL.
Basically in the same way, data can be transferred from display device 2 via the middleware 4 to the microdevice 1. For communications that are not limited to given localities, it will be possible to realize the first and/or second communications links EK, ZK, advantageously via the Internet. On principle, however, the first and/or second communications links EK, ZK can be realized in any common way, via wire, optical connections, or various wireless or cableless connections. Also, display device 2 may serve to include functionalities of microdevice 1 in applications, as web applications in the Internet.
The retrieval of data by the browser of the user interface and the functioning of middleware 4 are illustrated in
The middleware 4 takes care of all required activities, such as the establishment of communication links and the transfer of data, compression and decompression of files, etc. What the display device 2 sees, to the contrary, is merely an access or retrieval of the file listed in the script that is possible via its file designation.
Data caching that occurs in the middleware 4 as a buffering or caching for microdevice 1 can be realized in very different ways, while three special variants are more particularly feasible according to the invention.
In the prior art, to the contrary, caching or buffering occurs differently.
According to the invention, it is a particular feature that the unique identification as a file to be cached is given in the file name or file designation itself, that is, by stating the hash value. Metadata are not needed. The specific syntax used for this identification may take different forms, the decisive point being that this identification is contained, not in one of the HTTP header lines but in the file designation itself, e.g., in the file name or in the requested URL, thus, it is automatically contained in a href or src indication of a HTML or JavaScript file, is transmitted across all proxies, and will even arrive in this unambiguous form at the microdevice if the request could not be answered by a cache memory. It is the purpose of this approach that a specific file (having a unique identification) is downloaded exactly once, is stored in the cache for all subsequent requests of exactly this file, and is retrieved from there, regardless of the browser that happens to be opened, and regardless of the browser's own specific cache setting, also regardless of the device to which the request has been addressed, and of its URL A file once cached, for this reason is available to other devices as well, which makes sense particularly in the case of standard scripts.
It is simple here to install the caching mechanism:
Owing to the unique identification stating the hash value in the file name, files become globally unique. Their caching need no longer be assigned to a specific URL, nor to any specific microdevice 1. One or several online locations may then be designated as central storage locations for files to be cached, which makes sense particularly in the case of standard library files (e.g., JavaScript standard files).
Neither the browser nor a router or web server (including those of the microdevices 1) need to be altered, since we are dealing here with “normal” file requests without any change of the metadata or HTTP header. In the web server, the file is stored under its file name, which contains the unique identification. A separate processing of a unique identification as additional information (such as metadata) is superfluous. This makes the approach suitable for microdevices 1. It must merely be required that somewhere along the data transfer path between the browser or first computing unit 2 and the microdevice 1, a caching proxy or middleware 4 be provided, for instance just in front of the microdevice (middleware), at the router (middleware as “embedded middleware”), or online.
However, a file will not necessarily contain a unique identification, which is true for files having dynamic content.
The caching proxy or the second computing unit 4 where this caching mechanism has been implemented, automatically exercises a cleaning action: if the hash value does not correspond to the value computed from the content, then the file is regarded as a false file that can or should be erased from the cache. This secures the integrity of file content: a data alteration attack will have the effect that the file content will not pass the check, and thus its content will not be delivered to the browser. This check could be omitted in certain cases, e.g., in purely internal networks not having any connection to other, external networks.
It is an advantage having file names which in addition provide an indication as to the time of file creation. A date marker can be used to enable automatic updating of the local library. An automatic update may for instance be planned for each first of the month. A date marker also enhances legibility for the human eye, since-pure hash values are less meaningful and a search or examination via date indications is easier. Files to be loaded anew may then be identified via their date and loaded automatically.
The middleware may regularly and/or repeatedly send a request to the microdevice 1, and analyse its response behavior. Such a request may for instance merely concern the header of the index.html file and use the command “HEAD<SP>index.html”. From a correct and timely response of microdevice 1, it can then be concluded that the second communications link ZK is in good order. The response to any HEAD request made in a very low layer of the protocol will be restricted to the EOF character. In this case the protocol does not include any HTTP-like headers that would be transmitted by the microdevice 1 itself, but the middleware 4 supplements the corresponding HTTP header data and returns the HTTP request back to the requesting browser or display device 2, together with the associated header.
Instead of sending its own HEAD request, the middleware 4 may also monitor the link by monitoring the requests of the browser directed to the different microdevices 1, so that it can be established whether or not a functioning link exists. Thus, at times when requests are directed from the browser to the microdevice 1, a separate HEAD request initiated by the middleware 4 need not be made for a certain length of time.
It may be assumed that in the future, new data transfer protocols and/or new communications interfaces will be available as a standard in display devices. These will be added successively, so that it will be meaningful to plan for a possibility of flexible updates by a central place in the Internet during operation of the middleware 4. This can for instance be realized by writing parts of the software for middleware 4 in a programming language that admits a later addition of code. This is possible, for instance, in the case of Python. Here, code may be added later or currently (dynamically), e.g., by downloading from a central place in the Internet, and then executed.
When connecting a new microdevice 1 to the display device, then it will either be recognized or the user must tell the middleware 4 which product out of a selection of products it is. The middleware will then fetch the appropriate code and execute it. Subsequently, this code is included into the list of added codes that have been used up to that point, and may or should then find regular application when scanning connections automatically.
In the following, examples of microdevices 1 will be set forth where the method of communication according to the invention may be applied.
Small microprocesses are used in a multitude of applications in private and professional life while they are not perceived as electronic systems having such a complexity. They are found in domestic appliances, in simple measuring devices, in vehicles, chip cards, watches, heating controls, beverage dispensers, etc., that is, in nearly all electronic devices. Devices containing such microprocessors often have an operating surface that is of very restricted use, and non-intuitive, and that differs between devices in its design. With the method according to the invention, any such device when connected is open to user-friendly operation and setting via a display device that has browser capability.
A simple first example is that of using a Bluetooth module for an automatic door opener where the module (without any other microprocessor) handles the full management of several users authorized for access, and their connection data via Bluetooth (mobile phone), and mails Ajax pages to the browser of the mobile phone of such a user via Bluetooth. A simple door-opening function is realized via a relay that is attached and controlled by the module, and powers the automatic door opener.
The RSSI function of commercial Bluetooth modules and chips can also be used, specifically for initiating distance-dependent actions, such as the opening of a door in the above example, or the establishment of a connection.
A further example is a SmartCard or JavaCard used as web server. A SmartCard or device with integrated SmartCard chip contains a “single-chip” microprocessor capable of providing the computing power of a small calculator and a storage capacity of 100 kB or more. This is not enough for realizing complete Internet protocols or HTTP protocols (IP, TCP, HTTP), but enough for a connection within the scope of the method according to the invention. Apart from that, SmartCard chips are specifically designed as a “secure elements”, since they themselves are able to generate and store key data in a secure manner, while access to this key is far more difficult than on other microchips. Examples are the chips of the SmartMX family of NXP.
A simple file server that evaluates GET requests and answers them by returning the corresponding file as a byte sequence, and may also evaluate and perform an assignment of variables in accordance with the extension of the GET request (after the ‘?’), needs a memory of about 5-10 kB, and it is relatively easy, therefore, to accommodate it on such a chip together with applications software that may also be needed. This very limited memory is large enough to embed the following functions.
The transfer rate from the SmartCard or SmartCard chip to the corresponding partner device may also be limited. In RFID, depending on the reader this may be some 10 kbps, and attain about 400 kbps in NFC, but electromagnetic effects of the environment may depress these rates. This is too low if one wants to transfer the contents of voluminous document pages rapidly to a display device without waiting times for the user that are beyond the downloading times common in the Internet.
This implies that even in this scenario, the method of communication according to the invention can be used to provide the connection to the microdevice 1, while file contents may undergo intermediate storage in a cache as specified by the invention.
JavaCard is a particular embodiment of SmartCards where applications written in the Java programming language (JavaCard applets) may be loaded onto these SmartCards later, after they have already been issued to a user. In this way such a chip card becomes a card that may serve multiple applications. For instance, one and the same card may be used for obtaining cash from an automatic teller machine, and for authentication when entering a building. This multiple applicability of JavaCards has been greeted with hesitation by industry, the reason supposedly being that Corporate Identity as seen by applications suppliers (e.g., a bank) is too indistinct when the function of drawing cash from a bank account as an example could be placed on somebody else's JavaCard. The representation of Corporate Identity will be improved when, as described above, presentation contents are kept ready for every application in the file memory of the JavaCard. Thus, every applications supplier (bank, supplier of technology for building access) could put his presentation including logo, styles, etc. onto the JavaCard to make sure that this card will be presented to the user on a display device according to the supplier's ideas.
When implemented for instance in a SmartCard chip or JavaCard chip, this web server technology can also provide sophisticated operating surfaces tuned to the particular user. The microdevice 1 and/or the middleware 4 learn what the particular user group is, and may then present operating pages that have been individualized, and maybe even stored, for this particular user group or user. For instance, a microdevice 1 could present itself in different ways to a service technician, an administrator, a senior citizen or a young person that has logged in.
The concept described above, of caching certain data, not in the microdevice 1 but in a middleware 4, makes it possible to supply memory-intensive files such as company logos, graphics, library files more rapidly (ideally, even instantaneously) from the middleware 4 to the browser. It thus becomes possible to accommodate attractive representation pages including graphics content that matches the Ideas of Corporate Identity, even on small chips such as SmartCard chips.
A JavaCard chip normally lacks input/output pins, it is made as a pure server device, the main reason possibly being that it would constitute a security risk to provide the JavaCard chip and the reloadable applications running on it, with access to the I/O pins. This risk can only be managed in complex arrangements (such as a fixed, predefined local key for I/O access). In the following we present a simple and secure arrangement enabling a JavaCard to be incorporated into Hardware containing I/O pins which from the outside cannot be addressed, or only with an excessive effort. This is managed by connecting in series a simple logic chip or a simple logic function that will only convey all 7-bit data to the chip card, all other data being discarded since the 8th bit is not set. In this way only ASCII data and/or UTF-7-encoded data (or similar data) will reach the SmartCard-Chip. This will suffice, since the GET command defined above meets this requirement. At the same time, the SmartCard by definition may return ONLY 7-BIT DATA as a file response, that is, with the 8th bit not set. This does not constitute a limitation when using the protocol example given above, since again, without limiting the function, pure ASCII characters can be included. Now one can define that any data stream having the 8th bit set, as an instruction for the logic component implies that it should set its I/O pins accordingly, or read and answer with the 8th bit set Attention should be paid, however, to watch out for the peculiarities of the byte-based communication of SmartCard chips according to ISO 7816, and to recognize so-called APDUs and fixed commands based on standards, prior to setting an I/O pin. It is proposed to define a column of more than three consecutive bytes, all having the 8th bit set, as valid instruction for setting or reading an I/O pin.
In the specific embodiment, data communication for XML or json-based control of the microdevice from the display device—with browser via middleware 4—to the microdevice 1 is accomplished through the response to GET requests, where said response contains SSIs.
An example: a microdevice 1 driving a relay, and thus knowing a variable containing the condition of the relay (“REL”), may transmit the condition of the relay to the browser by means of the following .xml file, after the browser has requested the file REL.xml (transmitted “GET /REL.xml”):
- <REL>
Here, the chain of characters <l-#echo var=“REL”-> is the SSI tag referencing the variable REL. In the case of REL=1, the requesting browser will obtain the following response:
- <REL>
This file is readily evaluated with current browser language (JavaScript), and the text “ON” may then be displayed at a predefined position well visible to the user.
Content of a .json file “REL.json” which, as an example, dynamically includes the variables REL and DEVNAME:
When this file REL.json is requested, the microdevice then returns the following data content (as an example) when the relay is ON:
This dynamic file content can by compiled advantageously, by direct call of a function in the firmware, rather than via SSI. Then REL-json will not be a file of the file system but a code portion contained in the firmware and providing, in the final analysis, the answer desired.
The .json or .xml-based contents presented above have referred to a data presentation in known format. In the case of .cgi files, this is not necessarily so. For this reason, this file extension is used to characterize other dynamic contents that are not presented in known JSON or XML syntax.
In this way it becomes possible—while keeping the usual rules for file extensions—to build self-executing or self-representing, widget-like script contents with dynamic contents into a microdevice.
As a further application example, a system is shown in the following that makes it possible to simulate Ajax scripts on a web server that has been set specifically for this job but is otherwise a standard web server, such as the widely distributed Apache web server or a trimmed down and more open version such as Xampp.
This system consists of
The following simple example is intended to provide illustration, and is limited to few variables, such as the variable REL far “condition of relay”.
It is the particular aim that scripts designed for microdevice 1 are run on the simulation web server without any change, that is, without changes in these files, and are tested via the browser, without having to use the hardware of microdevice 1. Here the image of the variables, that is, the set of all variables and associated values, is provided to the scripts running in the browser in the same manner as would be the case with scripts coming from microdevice 1.
In this way one can test and simulate scripts intended for microdevice 1, extensively prior to loading them into the microdevice 1, as this loading may turn out to be a more or less complicated process and above all requires one to have the microdevice 1 as hardware. This should be done, not merely in view of the appearance of script design in the browser but also in view of the functionality resting on particular values of the variables, and in view of calculations and recalculations possibly occurring in the browser, and of displays appearing on the browser. The simulation is an exact one to-one simulation. A merely internal functionality that may occur in microdevice 1 may not be simulated, or may not be simulated so simply, because to this end a further device-specific simulation script would have to be devised on the server side. Here, however, the idea is that of running a server-side script (dev.php) that is independent of microdevice 1 and of its functionality and evaluates assignments of variables by the browser/user.
This will be represented for an example where the microdevice Functionality essentially consists in the ability of switching a relay with values REL=0 or REL=1 on and off, a device name exists with the variable DEVNAME, and a PIN exists with the identical variable name. This example will be demonstrated in terms of web server technology PHP. Basically, however, the concept can be transferred to other technologies such as CGI, Perl, Python, etc.
(1) Simulation file(s): A (main) PHP file “dev.php” exists where essentially the device variables are defined and the device functionality is simulated. In it, all device variables are defined as global variables so that they will be available to all other scripts to the extent needed. The names of these variables are kept uniform throughout for the sake of perspicuity.
Function in the simulator: in this simple example, the variables are initialized following the first call, e.g.: REL=1; DEVNAME=AJAXupPHP; PIN=1234. However, this initialization of the variables, may also be contained in a separate ini.php file that has no function at all in microdevice 1. Then prior to each simulation procedure, the file ini.php would have to be called.
This simulation file dev.php further contains any functionality that may exist in microdevice 1, such as internal calculations of values of variables or program runs. In the above example, for instance, the relay after switching on to REL=1 may automatically return to the idle state of REL=0 after a predefined period of time, possibly coupled with an internal time function.
Function in the microdevice 1: no function exists in this respect. The file dev.php is ignored when called with GET, or an empty file is returned. It might contain ini.php, but this should/must not be used by the scripts. In the final analysis, the microdevice 1 can only fill two functions that are managed, i.e., simulated, in the simulator by the PHP surface and by dev.php: on the one hand evaluation of the GET query string and execution of any assignment of variables that may be contained in it, and on the other hand parsing of .php files for the expression <?php echo=REL ?> and replacing this character string by the true value of variable REL, that is, 0 or 1.
Specific execution for dev.php, which parses or interprets any number of assignments of variables separated by “&”, and writes them into specific individual files associated with each value of a variable on the simulation web server. These individual files have a function, only on the simulation server, which is that of inserting the content into the place of a server-side include having the form of <l-#include file=“REL”->. In this way the same effect is attained as in the microdevice 1 while there is no need to change the file. All individual files for variables such as “REL” could in fact also be loaded into the microdevice 1—intentionally or unintentionally—but have no function there. For this reason one may load the entire set of files from the simulation server to microdevice 1 after successful simulation.
Sample File Dev.php:
The content of file “REL” (file name without extension in this specific example) is: 1, when the relay is ON.
The same content comes about when the browser starts a GET request in which the value of 1 is assigned to variable REL. On the server side, the above dev.php takes care that the file “REL” will obtain precisely this content. The corresponding GET request looks as follows, for example: GET dev.php?REL=1.
(2) Assignments of variables: Browser commands with which values of variables are to be changed are communicated in the GET query string from the script running in the browser (that is, after the n), and must be addressed to the dev.php, i.e., a switching of the relay to 1 would be formulated as follows: GET dev.php?REL=1.
Function in the simulator: The php-file thus called evaluates the query string “REL=1” that was addressed to it, and sets the global variable REL to 1. All other scripts when called have access to this variable with its new value of 1.
Function in the microdevice: this ignores the file request for dev.php and merely returns an empty file, that is, merely an EOF or a file with Content Length: 1, depending on the protocol. The GET query string “REL=1” is recognized by the microdevice 1 as command for assignment of a variable, and the variable is set accordingly.
The functions in the simulator and microdevice 1 thus are the same. One merely must adapt the microdevice 1 accordingly, so that it ignores the file request for dev.php and replies with empty content (i.e., only EOF), but interprets and executes assignments of variables contained in the GET query string.
(3) Inclusion of variables, file extensions: the interactive browser function comes about because files requested by the browser from microdevice 1 or from the simulator contain dynamically included values of variables.
The source file contains the character string <?php echo VAR ?>, which is interpreted by the microdevice and also by the php web server where the simulation is supposed to take place, in such a way that instead of this character string the value of the variable is included into the file, and this file is transmitted.
This automatic parsing can be set, both in the microdevice 1 and in the php web server for files with specified extensions or file terminations. This is possible for .php files, but also for any files used elsewhere that contain included values of variables, such as optional .xml, json, .shtml. It is important that these file terminations are set in the same way for the php interpretation in microdevice 1 and in simulation, i.e., in the web server. If this is the case, only for .php, which is often the standard setting of web servers, then pure data files—should they contain dynamically included variables—should also be executed with the termination .php.
(4) Simulator-microdevice-developer interface: A special page can be used to view the current values of the variables during a simulation of developed scripts. This may simply occur in a SHTML file having a refresh time set to a small value. In this case, .shtml must also be set as PHP-parsed file extension. It may also be a .php file simply listing all variables and indicating their values. Beyond that, this portal may also be used to change or enter values of the variables while the simulation is running.
Example No. 1: device.php (“developers device portal”) with the entry: <p>REL=<?php echo REL ?></p> etc.
Example No. 2: device-shtml with the possibility to enter values of variables, output of the current values of the variables (SSIs).
Example No. 3: device.json as file.
(5) Access to the simulation: The whole may run on a web server with PHP functionality, e.g., xampp, running locally or on external, rented web space, e.g., based on an Apache web server with PHP, and hence be available for third parties to have a look Particularly a testing where different browsers such as the Microsoft Internet Explorer (MSIE), Mozilla Firefox (FF), Opera (opera.com), and Browzar (browzar.org) are used, proved to be very important and often has required a “tweaking” of script code until the scripts would run perfectly on all these browsers. Simulation offers the possibility of doing this efficiently, and even in parallel.
(6) Interface between a microdevice developer and an Ajax script web designer in view of an example including a single .json file for a microdevice 1 having a name (DEVNAME), a personal identification number (PIN), and two users with an address (USERx_BDADDR) and a name (USERx_NAME) each:
Here a format is specified for the developer in which he may enter his microdevice variables that he names or transmits to the web designer, including default values for the purposes of simulation, and including a description. The web designer can include this device.json file at once into the given simulation web server, where for instance a PHP script, e.g., ini.php, will perform an initialization procedure on the basis of this json file where the values of the variables are initialized. The above device.json file at the same time contains all associated SSI variables, and may therefore provide the full picture of the variables to a HTML page or SHTML page or Ajax page available to the developer, so that they may be presented in a clear way.
Using particular settings, the simulation web server can be set in such a way that it will behave just like microdevice 1. It is assumed here that in the simulation, for each variable an associated file is available that contains merely the current value of the variable. The web server setting should more particularly perform a server parsing of SSIs in all those files that contain SSIs, e.g., .shtml files, json files, .xml files, .ssi files, and .inc files. It will also be advantageous to set the server in such a way that .shtml files are recognized by the browser as HTML files, rather than as undefined files, and that they are displayed as such, and not offered automatically for download as is done by some browsers. It will finally be advantageous if the web server will include a line with “expires:”, followed by a date that has already expired, into the HTTP header of all .shtml, .json, .xml, .ssi, and inc files. In this way one makes sure that the browser will not cache these files, that is, will not fetch them from some intermediate memory, but will always request them anew when a script entry requires it.
A further applications example is the inclusion of microdevices 1 via a middleware 4, as web widgets into online web pages. A web widget is understood here as the inclusion of a web page, such as a microdevice surface, into another web page, e.g., online account. It is very easy, basically, using the “iFrame” technology to simultaneously represent in a single HTML page two web pages having different URLs. Two web pages are represented practically independently in well defined frames within a single web page. The problem that arises here is the inability of these two frames to exchange data with each other, a feature implemented for reasons of security into the browser functions. This represents an essential limitation for the method of communication. For the user, it is advantageous if device GUI data can be shifted to the online web page, or if the data of the microdevice 1 can be put to use in another form in the online account, exactly as if the microdevice 1 was part of the online application.
The iFrame method mentioned is not suitable for that. It is not technically possible, moreover, to send an XMLHTTP query to another URL, it can only be sent to the same URL from which the web page currently displayed comes. This is also prohibited by modern browsers for reasons of security. This means, it is not possible in an online web application with the sample URL http://www.onlineapplication.com/index.html, to send an XMLHTTP query to a device having another URL, for instance, http://localhost:10000/index.html.
The first possibility of a solution to this problem is that of asking the middleware 4 to pretend to the browser that a single URL is present, while the individual inquiries, however, are sent either to www.onlineapplication.com or to localhost:10002, depending on the addressee: the online server for the web application or the microdevice locally included via the middleware 4. In this approach to the problem, the middleware 4 represents a single URL for the browser, e.g., http://localhost:10000/. Now all queries may be forwarded automatically without any further protocol statement “http://” to the microdevice 1. The request to http://localhost10000/index.html is passed on as “GET/index.html” to microdevice 1. All queries indicating an online URL using a new protocol statement rather than the file name are then forwarded into the Internet, e.g., http://localhost: 10000/http://www.onlineapplication.com/index.html. The middleware 4 recognizes such an inquiry by seeing that instead of the expected file name, a protocol statement including “:” D follows, so that this cannot be a file name. Thus, for the browser, both URLs, the microdevice URL and the online application URL, appear as one and the same current browser URL, that is, in the present example http://localhost:10000/.
A further possibility for including microdevices 1 as web widgets by means of middleware 4 is given by the JS or JavaScript method. As an alternative to the problem approach presented above, a possibility exists to gain direct access to the microdevice 1 from an online URL that is the current browser URL, even without extending the functions of the middleware 4, viz., using the normal HTML entry of a JavaScript source being requested.
This entry is for example given by: script type=“text/javascript” src=“http://localhost:10000/devicewidgetscriptexample.js”>.
Here the browsers apply no URL check, and send this query even to URLs not matching the current browser URL. The same principle is applied as well by Google Analytics.
For the method of communication according to the invention, however, the hurdle still exists that the data content of a file requested in this way cannot be viewed by the browser—the browser has no access to the individual bytes of the file. Only preestablished browser functions can be used, such as display in the form of an image or execution as a JavaScript file. The latter may be used by filing JavaScript scripts that can be executed in the device, as a kind of web widget code, as it were, and these can then be executed by simply requesting this JavaScript file via a uniform command from an online web applications web page.
A variant of this solution is shown in
A fourth embodiment of the method of communication according to the invention is presented schematically in
The concept of a software cable can be extended to router devices.
An exemplary data format for such a device list looks as follows:
Contents of DEVLIST.json:
Here, DEVADDR is a unique terminal device identification, DEVNAME is the legible device name, DEVTYPE is an indication of device type, possibly given in a globally unique way, and in the last column the indications of DEVLIST.json (or another directory file) are an indication that this terminal device is once again a router device with device directory.
A middleware that is executed recognizes when seeing such a device directory such as the DEVLIST.json shown above that it has to do with a router microdevice to which further terminal devices are attached in turn. Communication with a terminal device may now be established by sending a request or inquiry to the router microdevice that in front of the file name includes the (unique) identification of the terminal device, such as DEVADDR. The request then looks as follows: GET/[DEVADDR1]/index.html, when requesting the index.html of the first terminal device. Here, [DEVADDR1] stands for the unique device address of the first terminal device connected.
The router microdevice may have its own GUI (though this is not compulsory), in that it will respond to an inquiry GET/with a corresponding content (default file) that can be represented in the browser. Then even this microdevice may be operated by a user, and settings may for instance be edited without the need for own software.
The communications between the individual terminal devices #1 . . . #n may again follow the protocol according to the invention that has been described for serial transmission pathways, but it may be a protocol, more particularly when working with ZigBee, that maps the HTTP-like request and response messages onto transfer packages, in this case onto ZigBee packages.
It is not compulsory that the above microdevices are only based on ZigBee or RS485. We talk about exemplary implementations. More particular, any wireless or cable-bound transmission methods can be used to link one or more than one terminal device to a USB port, such as UWB, Bluetooth, Wibree, RflD, USB (direct), RS422, field buses such as Profibus, etc, etc.
In the case of “USB”, too, we may have to do with other buses customarily found in PC, such as PCI, Mini-PCI, LPC, I2C, etc.
The middleware here contained in memory component 14 on the router microdevice, preferably is a generic middleware not oriented toward a specific function of associated minidevices or of router microdevices having further terminal devices. This means that at any later point in time a terminal device having a new functionality may be attached, and this functionality is automatically available to the user since the corresponding GUI scripts are contained in the device or are unambiguously referenced. Thus, for the distribution and maintenance of particular applications/GUI software, the administrative effort is nil or small, and current device innovations can be introduced in a simple way into existing device systems.
The system-specific examples notwithstanding, the method is fundamentally useful also for other forms of data holding and communication. The design of data formats and the logical and physical maintenance of the data in particular can be adapted by one skilled in the art, without any problems to different systems.
| Number | Date | Country | Kind |
|---|---|---|---|
| EP 0 810 194 1.6 | Feb 2008 | EP | regional |
| Number | Date | Country | |
|---|---|---|---|
| 60909764 | Apr 2007 | US |
