Preface
Chapter 7: Implementing Successive Releases of ERP Systems
7.6 Product Markup Language for the Smart Materials World
This chapter makes several references to the need for better tools, beginning in the introductory remarks, which brought to the reader's attention the Product Markup Language (PML) for describing physical objects. PML is based on the eXtensible Markup Language (XML), which is a development of the Hypertext Markup Language (HTML), the common programming tool on which most Web sites are based.
HTML enables any user to surf the Internet from a desktop. But whereas HTML tells the computer how information should be displayed, XML goes a step further by instructing the computer on what kind of information the user is viewing. Microsoft has developed Visual Studio.NET, which is an XML-based tool. It is both a programming model and a means for rapid application development. The object of Visual Studio.NET is to make possible easy delivery of highly distributed programmable services
running across stand-alone machines. These can be located at corporate data centers or in the Internet environment. This is commendable, but it is not enough with smart materials. MIT's PML goes further:[4]
It helps in building-in layers of increasingly specific data to describe physical objects, their configuration, and their state.
It provides instructions for machines that process or alter a product, such as motor vehicle processors, microwaves, machine tools, and other equipment.
Together with the Electronic Product Code (discussed in Section II), PML satisfies the basic
components needed to automatically link information with physical objects. In other terms, it provides urgently needed connectivity between the physical network and the logical or digital network.
PML functionality is found beyond handling static data. This choice was made in appreciation of the fact that there is a need to communicate dynamic data: that is, information that changes as a product is being used, ages, or is consumed. Examples are changes in weight, volume, temperature, moisture, pressure, and other variables being tracked through metrics. In principle, a company should not forego a new release that includes PML.
The design of PML accounts for the fact that future applications will most likely need to include software that describes how an object behaves. For example, a PML file may contain the program that says how fast a resource will be used before it needs to be replaced — or how fast a production process will run out of inventories, given available levels and current consumption.
In connection with smart materials applications, there is also a need for an Object Naming Service (ONS) that ensures that the physical network and the logical network can effectively work together. The object is to provide universal connectivity between objects in the physical world and their digital
mapping. Some of the challenges currently addressed by researchers at MIT's Auto-ID Center include how PML will:
Handle both static information and streaming, dynamic data from physical sensors
Accommodate individual objects, bit object hierarchies, assemblies, and aggregates
Facilitate distributed management of product and process information at central locations, such as factories, warehouses, and sales outlets
Provide for security (preferably embedded in the language) to ensure that proprietary information is protected
Still other challenges are making feasible ways and means for software changes and upgrades to take place simultaneously and immediately; guaranteeing that products are linked with the most up-to-date data; enabling real-time access to critical information; channeling online recycling instructions; and including multifunctional timestamps at product and process level. Full support must be provided for scripts and scenarios, device drivers, control systems, and the intelligent management of an environment.
A major challenge is that of software testing in connection with applications that can be as diverse as the administration of a supply chain, enterprise resource planning, customer relationship management, and other implementations in-the-large, and also novel applications in-the-small, such as smart
appliances, automatic check-outs, theft deterrence, focused advertising, instant service manuals, and dynamic pricing.
Finally, whether talking about new tools or old ones, development toolkits or entire applications, programming products or in-house routines, always keep in mind that software testing is an
indispensable part of software development, implementation, and maintenance. It consists of executing a program with the intent of finding errors, omissions, and bottlenecks in the code. Only exhaustive testing can give some assurance about the absence of errors in a computer program.
If for some test the software behaves incorrectly, then it is either inexact or it contains errors. However, if it behaves correctly, this does not mean that it is free of errors. All it means is that the errors were not found. To repeat this statement: if the tested program behaves correctly, this only shows that with the test method and the test data being used, it works.
It is precisely because of this uncertainty between the part and the whole, the visible error and the hidden error, that exhaustive testing is done to establish a degree of confidence that a computer program does what it is supposed to do. This is accomplished by means of test cases involving description of the input data and of the correct output for that set of input data.
The best policy with test cases is that they are written to explore both normal conditions and outliers; for example, invalid and unexpected input/output conditions; twists in the processing sequence, which are
unlikely but possible; loops that might not have been evident at first sight; and other events of relatively low likelihood but still able to upset a computer program.
Test cases should cover all the syntax and semantic rules of the language. In the special case of PML, they should incorporate dynamic data; and in all advanced software cases, they should generate opportunities for errors in all contexts in which the program is expected to run. A test case is thought to have passed its testing process if after compiling and executing, the generated output matches the expected output not in one but 100 or more repetitions.
In conclusion, one of the main problems in software development, testing, implementation, and maintenance is the impossibility of ensuring a 100 percent coverage of the system undergoing the sort of critical examination being espoused. In science, one is more sure when one rejects a case (or a theory) than when one accepts it. Any acceptance is tentative because it only means that thus far no reason(s) have been found for rejection.
[4]See also PML's contribution with smart materials, in Section II.