Scribd Logo
Upload

Welcome to Scribd!

  • Mobilni Uređaji I Servisi

    Uploaded by

    Tony
    3 views19 pages
    MU

    Original Title

    Mobilni Uređaji i Servisi

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document
    MU

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    3 views19 pages

    Mobilni Uređaji I Servisi

    Uploaded by

    Tony
    MU

    Copyright:

    © All Rights Reserved
    Download as PDF or read online from Scribd
    Flag for inappropriate content
    of 19
    Chapter 9 Mobile Devices and Services Erkki Jantunen, Christos Giordamlis, Adam Adgar and Christos Emmanouilidis Abstract. E-maintenance and the use of mobile devices offer the flexibility to ini- tiate maintenance-related applications at flexible locations while networked in un- structured environments. They are becoming a key enabling factor in achieving ubiquitous data and services availabilty, by retrieving information from heteroge- neous data sources. Personal digital assistant (PDA) devices play a key role in bringing mobile maintenance management closer to daily practice on the shop floor. ‘The use of PDAs enables maintenance personnel to directly gain access to in- formation stored at different locations, whether this be in the back office, on the ‘monitored machinery or even outside of the plant. PDAs are becoming a ubiqui- tous information and services mediator, bringing the right maintenance-related in- formation and e-applications to the right place at the right time to anyone author- ised to gain access. Mobile users can again consult and act upon information, such as data relevant to monitored machinery, e.g., condition monitoring readings, the current machine state, maintenance actions history and scheduling, spare parts availability, maintenance activities instructions. In this way, mobile devices and services constitute a mobile assistant, enabling information and applications ac- cessibility by mobile personnel, greatly expanding the available toolset with en- hhanced data and knowledge processing capabilities. 228 B,Jantunen et al 9.1 Introduction Mobile devices, typically in the form of a PDA, are central to the implementation of mobile e-maintenance solutions. In the DynWeb architecture a PDA is a multi- purpose device, communicating with smart tags, intelligent wireless sensors, web- services and semantic web information. The rapid growth in the mobile devices market indicates that a device-type choice is not straightforward. It further indi- cates that as technology and costs are changing rapidly in this area and new prod- ucts, devices and software enter the market, ensuring a high level of interoperabil- ity is more important than tying a solution to a specific type of device. This need can be addressed by specifying a minimum set of hardware requite- ments for the mobile device, a set of web-service applications to support the e-maintenance functionality, and a common interoperable format for data ex- changes, tailored to the maintenance function needs, Undoubtedly this trend will continue and many more devices will become available in the future. It can be reasonably predicted that costs will reduce whilst power and function- ality will increase, In this setting, the primary factors on which the hardware deei- sion was made concerned the key technical features of the device, with special at- tention on connectivity issues, as this is very important to enable rapid and reliable communication with other devices. Secondary factors such as unit robustness, aestheties, efe., were not considered due to the rapidly changing nature of the market. Applications were defined as typical web-services with published interfaces, while database support observed MIMOSA (www.mimosa.org) specifications to ensure services and data interop- cerability A PDA js a tool that enables the maintenance technician or engineer to inter- face and communicate with the surrounding world (Jantunen et af, 2008). It is a ‘mobile user interface that provides access to the computerised maintenance man- agement system (CMMS) employed for the management of maintenance person- nel, materials and activities. By enabling fast and flexible access to remote web- services, the PDA can operate on a semantic web based platform, such as Dy- naWeb developed within the context of the Dynamite architecture, offering many support tools to the maintenance engineer. ‘The PDA also provides access to the identification of the machine and to condi- tion monitoring data, as well as diagnosis of the machine condition. Usually the PDA is employed in thin client architecture, i., most of the data is located and processing takes place in the central computers providing e-maintenance services, Since itis not always easy to automatically diagnose the condition of a machine, it is natural to include the condition monitoring and signal analysis capabilities also on the PDA. This dual functionality both takes into advantage the powerful capa- bilities of a remote server system, as well as the flexibility offered by the mobile device (o bring information and services accessibility at mobile locations, such as ‘on the shop floor or even outside the plant. “Mobile Devices and Services 229 9.2 Mobile Devices in Maintenance Management Since their inception (Chess et al. 1995), mobile agents have been used in a wide variety of applications (Jantunen ef al. 2007). There are several advantages in em- ploying mobile computing compared to conventional desktop applications. ‘Among other things, mobile computing offers the flexibility to initiate applica- tions at flexible locations in unstructured networked environments, to quickly and efficiently search for and retrieve relevant information from heterogeneous data sources, o perform tasks while utilising limited or intermittent connectivity and to provide asynchronous services to client requests (Samaras 2004). Adding the ease and flexibility of carrying a handheld wireless device, mobile ‘computing has the potential to transform the way in which a range of industrial ‘management, monitoring and control tasks are performed (Buse and Wu 2004, ‘Amnaiz ef al. 2006). This potential is still largely unexplored in maintenance man- agement, Although the usage of wireless devices within an e-maintenance frame- ‘work has been suggested in the past (Lee 2001), integrated maintenance manage- ‘ment solutions based on combined usage of wireless sensing, RFID tags, hand- held devices and central or remote server-side computing and dats-offices (Lampe et al. 2004, Legner and Thiesse 2006, Wittenberg 2003) have only recently started to emerge. Part of the difficulty is attributed to the challenge of integrating equipment, de- vices, computing resources and codes from heterogeneous sources (Bartelt et all 2005, Trossen and Pavel 2005), this being further complicated by the considerable complexity of optimising the management of maintenance in modern industry (Amaiz ef al. 2006). In DynaWeb the usage of PDA devices plays a key role in bringing mobile maintenance management closer to the daily practice on the shop floor. PDAs are used in synergy with intelligent sensing devices and smart tags on the lower-end of the data processing architecture, but also with server-side data- bases, data processing and remote access applications at the higher-end of the ar- chitecture, Here the hand-held device is employed within thin-client server architecture (Gantunen ef al. 2007). The “mobile worker” (technician), equipped with the PDA, approaches the monitored machinery. The PDA is equipped with an RFID tag- reader enabling the automatic identification of the equipmenticomponent and thus it becomes possible to automatically retrieve relevant data from the central system (historic and reference data database) and quickly present it to the user. Further- more, the PDA can access measurements logged at the intelligent sensing device (sensing agent) and combine/compare those with the automatically retrieved re- Tated historical and reference data from the central database, but also with domain knowledge from the central KBS (server KBS). ‘Thus the PDA becomes a ubiquitous expert advisor and, at the same time, flexible data collector. Within this architecture there can be several intelligent sensing devices, distributed across the plant, which can wirelessly transmit data 230 B,Jantunen e al via short range RF either directly or indirectly via data logger gateways from the shop floor. In this manner, instead of an inflexible, costly and rather inaccessible wired monitoring structure, we have @ flexible, easy to deploy and operate wire- Tess e-maintenance architecture, which can become a powerful, efficient and easy to use tool for the maintenance engineer, while, at the same time, can be integrated with the organisation BRP. 9.3 Role of PDA Within DynaWeb The PDA is a key element in the DynaWeb structure and it is arguably the most essential element in making mobile e-maintenance possible in practice (lantunen et al. 2007), Here the e-maintenance concept is defined as the system or approach that enables maintenance information and application services availability at the exact location where they are needed, i.e., in most cases near the machinery. Fol- owing this definition, the role of PDA is defined as a mobile user interface to the maintenance web services platform, DynaWeb. In the Dynamite project the key features are: (1) smart tags, (2) intelligent MEMS and oil sensors, (3) wireless data acquisition, (4) semantic web and (5) cost effective maintenance. ‘The information flowing from each of these sources is required to be collected, assimilated, analysed, processed and presented to the user at the PDA. Therefore, all the above information sources should be made accessible to the mobile user. This is achieved through the choice of an appropriate PDA and associated hard- ware, the development of suitable software and the customisation and integration of adequate wireless networking solutions. Thus the PDA supports; ‘© The use of smart tags for equipment component identification, storage and hhandling of component data, details of maintenance actions and machine diag nosis results * Wireless communication with intelligent sensors and local signal analysis and diagnosis, © Communication with the CMMS system for handling asset and spare parts in- formation, work orders, asset identification and localisation, etc. * Communication with the semantic web platform, DynaWeb. = Cost-effectiveness analysis, ‘© Logical and efficient display of raw data, processed data and summary infor- mation based on the above features. Table 9.1 summarises the main PDA functions developed. Many of the inputs are from sensors that can be connected to the PDA or from Mimosa-compliant da- tabase tables. Naturally most of the output goes to the Mimosa database, either lo- cated in the PDA or at the server, depending on the availability of a wireless con- nection, ‘Mobile Devices and Services 231 ‘Table 9.1 Summary ofthe PDA functions supported in DynaWeb PDA actovrole Definition of production ma- chinery Segments Assets Definition of measuring systems Sensors Locations Iensiication of machinery ‘components plant floor Condicion monitoring ‘measurements Vibration ‘Constion monitoring ‘Temperature Pressure Vibration Condition monitoring analysis, water content, particles, et “Manual monitoring of production machinery Diagnosis of machinery condition Prognosis of machinery ‘condition ‘Work onder creation “Manual creation of work orders ‘Work order scheduling, user interface to scheduling sr Opcional ard ‘None None RFID reader DynaWeb vie bration sensor USB host port, ynaWeb wire- less sensor package DynaWeb gate way DynaWeb oil Noneuncoo ‘ected manus None None Input from “The maintenance ‘engineer defines it ‘onsite “The maintenance engineer defines it RFID wag Mimosa database Sensor Gateway Mimosa (ol sensors Send daa to server and that canbe studied with the PDA) Manual inpot ‘Maaual input of work ‘orders and work order steps Mimosa = Work orders Ourput to Mimosa Segments Assets Tables Mimoss Measuring Tvcations ‘Sensors Tables Mimosa Spectrum Parameters Minos Parameters ‘The seings of oil sensors can be modified through WEB connection Mimosa Mimosa ‘Work orders ‘Work ard steps Work onder steps 2olko stojic@sve-mo.ba 232 B,Jantunen e al Table 9.1 (continued) PDA actortole Optional hard- Input from Output to Handling of work ordess None Mimoss and work order steps that have been assigned tothe maintenance engineers = Work orders = Work order steps Guidance to carry out the None Maintenance guide maintenance work database The specifications of the handheld PDA device, including hardware and soft- ware requirements have been previously defined (Jantunen et al. 2007). The pri- mary hardware elements include the PDA itself, the wireless hardware and the [RFID or smart tag hardware, Among the choices, the following may be outlined: the hardware device must be a commonly available ‘off the shelf” product to allow ease of use by any potential system user. The processor speed should be sufficient to satisfy processing and display requirements. A processor at least as efficient as Intel XScale PXA270 should be suitable for the tasks in mind. The device connec~ tivity needs should be met by sufficient networking and interfacing support, al- though additional hardware (an RFID reader) is needed for RFID communication, The sereen resolution of the device is to be 640 x 480 pixels, ie. standard VGA. This is sufficient for the typical information that needs to be displayed and is supported by a growing number of devices. The chosen operating system is Windows Mobile or Windows CE, as itis a very widely used system on mobile devices (antunen et al. 2007). The operating system should be NET compatible, for consistent development of the software modules. One consequence of this is that many popular types of PDA hardware such as Nokia Smart Phones or Black- berry (very popular in USA) cannot be used to run DynaWeb during the develop- ‘ment phase of the project. The device must have long battery autonomy for atypical operator shift length, Although RF data transmission is power consuming, the typical use of the device does not require continuous RF activity. The PDA device should be of a size and weight that allows easy portability around an industrial type site. It should be typi- cally much smaller than a light laptop-computer (< 1 kg). Manual data entry should be supported by a range of standard methods. Typical PDA devices will al- low several ofthe following methods: ‘touch sereen, pen browsing, usually more comfortable than a keyboard in small devices. Alphanumeric keyboard, numeric input to connected device is easier. © Qwerty keyboard, some letter input is somewhat possible. ‘© Easier letter input. Many of the keyboard options are actually supported by the on-sereen touch keyboard. “Mobile Devices and Services 233 ‘The PDA device should have a USB host to be able to collect data from a con- nected vibration sensor. This gives the advantage provided by active sync pro- {grammes and also allows cable communication for backup purposes. Bluetooth communication is an interesting possibility for the PDA device as it allows connections between other PDAs to sensors and to phones, etc. This may be a useful feature to include in the PDA specification, e.g., for device calibration or setup purposes. The RFID reader should be compatible with the PDA device. A convenient solution is via a compact flash card RFID reader, which can be added or removed from the PDA as required. ‘Additional identification capability could be included by the use of a laser bar- code reader. This would provide a backup for machine identification, A final backup strategy would be to enter the Asset ID manually via the PDA on-screen keyboard, Other possible solutions require a free SD, CF or PCMCIA card slot. 9.4 Description of Typical PDA Usage Scenario in Maintenance Operations In order to illustrate the typical use of the PDA within a maintenance management system, an end-user scenario has been created. The example considered in this scenario is a typical sequence of events that would occur when a maintenance technician user is performing a routine inspection tour, Prior to the defined s. nario, the maintenance engineer would have defined the segments (machinery) and assets (components) he would be taking care of (see Figures 9.1 and 9.2) ‘The shown inspection routine is a very common set of activities that can be ap- plied to a wide range of applications, The user actions together with the actions triggered in the software are described below. For clarity the software elements are shown in fixed-width font, Step 1 ‘The user will typically be walking around a production facility and would like to ‘make inspections of various pieces of equipment or machinery. When approaching the machine the user can use the PDA together with the onboard RFID reader to scan the tag of that particular machine. This will return the unique RFID code of that tag, ensuring that the machine is correctly identified. ‘The software uses the ‘unique ID of the tag (unique to that machine) to perform a query on the MIMOSA database in DYNAMITE, The query will return the model ID of that asset, so that the user is clear as to what the piece of equipment is and what its Function is. Query Asset (RFID asset info including “Model Code” iel_db_site, model_db_id, m del 234 B.Jantunen etal fa ype = 159 (et, sue) ype code = 8 segraneld =2 gmt ast updated » 6/6/08 ae [ator] Festres || nfo Figure 9.1 The main menu in the PDA, igure 9.2 Detaled information about the ser imerface asset Step 2 Once the asset and model ID have been identified in this way, the next step is to determine the model code. Another query is used to return the model code of that, asset. The model code and other related information may then be presented to the user on the sereen of the PDA. The user can then confirm that the machine is the ‘correct one and that the inspection process can begin, Query Model (Model Code} to obtain the model information. Step 3 Al of the possible events that could occur (e.g., machine failures) are pre-defined in the MIMOSA database and hence it is not necessary for any information to be stored on the PDA. The events need to be determined. This is achieved by again performing a query on the asset_event table in the MIMOSA database. This table holds the different types of possible events for assets. These include both operat- ing events and failure events such as time-stamped facts, logged operating events, failure “modes”, failure “effects”, failure “mechanisms”, defect events, abnormal situations, alarm events, efc. An event is not work performed by an entity, but «log of the actual events that occurred at an asset over time. zolko stojic@®sve-mo.ba “Mobile Devices and Services 38 Query ModelBvent (Model Code) fora list of Event type codes” (= ev db site, ev db id, event_type code) Step 4 From the list of asset events determined earlier, the type of events applicable to the particular machine must be determined. For the purpose of the demonstration of this scenario, the event to be flagged will be that the machine is dirty (and therefore needs cleaning). ‘At this point the user will be presented with a checklist of observations for this machine, All the observations that have been made can be recorded. For instance, iff the possible faults for a machine were as shown in the list below, then the cor- rect action would be to checkiselect the “cleaning LTA” option to indicate that the ‘machine was dirty. ‘Wrong component installed Balancing LTA, Alignment LTA, Broken seal (Cleaning LTA v Belt resonance Shaft eccenticity Emission, recorded Figure 9.3 Sub-set of posible machine observations specific to the machine being observed, “bell esonance” would not appear on equipment with no bet ‘The entry in the MIMOSA database will be “cleaning LTA” Note: LTA = less than adequate Query _AssetBventType (Event Type Code) returns all different possible event definitions for that particular machine. Step 5 ‘The next step is to determine the agent identity (usually a maintenance techni- cian). This can be approached in two ways. The PDA can be determined to be the agent, in which case a code can be assigned to uniquely identify the PDA. Alterna- tively the PDA user can be found by scanning an RFID badge on the user, or by password login atthe start of the user session. Query Agent (RFID) this retrieves the agent (user) information from the database, 236 B,Jantunen e al Step 6 The next stage is that an asset recommendation is ereated. Create _AsssetRecommendation (asset code, agent ime, recommendation comment} this ereates a new recommendation record From the previous examples it is clear that the software can guide the user through typical maintenance procedures extremely efficiently. The communica- tions with the database are quite complex; however, this is almost completely hid- den from the user. To continue the example, the following steps may be completed. Details of the data base communication are omitted for brevity Step 7 An agent (in this case a piece of software residing on the server) checks in the da- tabase for any automatically generated or user inputted data that describe occur rence of significant new events Step 8 ‘An agent (again on the server) translates the new event to a recommendation. This is achieved by a set of web services (state detection, diagnosis) for rapid and con- sistent decision making. Alternatively, the agent could be triggered from the PDA instead of running continuously or at regular intervals. For efficiency of operations with large databases there would most likely be a combination of the above ap- proaches. A service would be requested (condition monitoring or state detection, and diagnosis) from the Mimosa event data, Step 9 Recommendation is translated to a work order by a software agent routine on the Step 10 The PDA may then be used to display the current list of work orders, see Figures 9.4 and 9.5. This can be achieved via a simple query on the database. These results can be fillered by user to present an individual work list for each individual system user (maintenance technician). Alternatively an agent can be programmed to ex amine the work order table in Mimosa and then send these work orders to the maintenance personnel, Ze, to the correct PDA. This would be done by a web ser- vice (TssueWorkordertoPDA) to identify the most suitable PDA. The PDA can also be used to help carry out the maintenance work (see Figure 9.6). “Mobile Devices and Services 237 Work Order Steps [F- Galbate Devo 2 eset barins wi Ds Figure 9.4 Managing work orders Located inthe Manufacturing Lab ‘Secuky Aspects lx Operations are tobe perfméd under the supervison ofthe Maitenance offer > Fiat Bags Sainte Gere a Figure 9.6 Presenting an object's information 2olko stojic@sve-mo.ba 238 B,Jantunen e al 9.5 Wireless Communication The PDA is expected to provide anytime availability and have the capability to pperform all the tasks listed in the previous sections. From this definition it follows that the PDA must be equipped with wireless connectivity, so as to establish communication between the maintenance centre, the machine, the tags and the sensors. Different technologies are used for wireless communication, depending fon the requirements for the connectivity range, throughput and operating envi- ronment, ‘A wireless local area network is commonly available in many built spaces pro- viding Internet access and through that access to the needed web services. How- ever, WLAN might not always be available and it might also be very impractical for regular heavy duty data transmission, such as partial copies of the maintenance related database and therefore it is natural to also have a wired link to the PCs that support the maintenance personnel. Usually the wired link today is based on a ‘USB connection. The same USB (host port) connection can also provide access to sensors and data acquisition components that support it. For the communication with smart tags an RFID communication link is needed, usually provided through an RFID tag reader that is plugged into a PDA, CF or SD. In some cases, the sen- sors and data acquisition equipment may support a Bluetooth connection, which is commonly available in other devices, such as printers and phones. For complex sites with multiple building facilities, if outdoor localisation is needed then a GPS receiver should be included. If the maintenance engineer is ex- pected to be able to carry out all tasks with the same device, then mobile phone connectivity is also needed for communication with the phone, fax and email. The phone link can also provide Intemet access, if a local area network is not avail- which may still be the case in many places. In fact, in the case of maintaining mobile machinery, itis not probable that WLAN would be found in practice. In DynaWeb the wireless capability of the device has been chosen to be that of WiFi (antunen et al. 2007). This is the common wireless local area network (WLAN) technology based on IEEE. 802.11 specifications. This has been devel- oped specifically for mobile computing devices, such as PDAs and laptops, in LANs. More standards are in development and they will allow WiFi to be used by many more consumer products and vehicles. This technology is envisaged to greatly extend the potential uses of DynaWeb in the future. The only disadvantages that may apply to DynaWeb include the following. Wi- Fi can suffer from interference caused by other wireless networking devices, oper- ating at the 2.4 GHz band, such as cordless phones and microwave ovens. Power consumption is fairly high compared to some other standards, making battery life and heat a concern. Wi-Fi networks have limited range, typical router/antenna combinations might have a range of 45 m indoors and 90 m outdoors. Wi-Fi inter- ference can prevent access, caused by overlapping channels, which can be a prob- lem in industrial or commercial environments. “Mobile Devices and Services 239 9.6 Technical Requirements From the maintenance engineer's point of view, an optimal PDA would have all the communication features described above and it would also be small and easy to carry around (Jantunen ef al. 2008). Unfortunately, the demand of small size and light device is somewhat contradictory to the technical capability of the de- vice, Especially the screen size and resolution are of great importance when the device is being used for, e.g., showing a video of how to dismantle a device or ‘when a report has to be filled in. ‘When looking at the market it would seem that a small size is appreciated more than the screen size, ie., it seems that devices that are capable of VGA resolution are typically used for making condition monitoring measurements and communi- cation with the CMMS. A fullsize keyboard would be the nicest way of writing information in reports and messages. Unfortunately a keyboard does not fit nicely into a small device, ‘Today it seems that small keyboards are becoming more popular in devices used in communication. However, it should also be remembered that the main task of & maintenance engineer is to keep the machines running and not to communi- cate with other people or systems. In fact, it seems to be a common experience that maintenance engineers do not like writing reports, ie., itis something that is considered a necessary evil and is also avoided if there comes an opportunity to do ‘Another issue is that the so called “prose’-type maintenance reports, which in a verbal way define what has been done, are not a good way of collecting valuable historical data that could support the maintenance planning work. Instead all re- ports should be made in a very formal way so that the CMMS can easily use the data. This issue has usually been solved using check lists where the user ticks the ‘options that correspond to what has been done. Luckily this kind of methodology fits the PDA well and is also easier from the maintenance engineer point of view. 9.7 Practical Limitations Today There is rapid trend in the development of both PDA hardware and software to manufacture devices that are faster, equipped with larger memory and enhanced features, while at the same time the software development tools are increasingly enriched in order to take better advantage of the hardware development (Jantunen et al, 2008). Currently, there seems to be quite a number challenges in practice. In many places the supporting environment docs not provide wireless communi tion nevworks or the intermittent nature of the connection hampers the completion of the PDA tasks. 240 B. Jantunen eta Furthermore, if all the features of the PDA are simultaneously used, the battery pack does not last for one working day, ie., the device has to be turned off for some periods or it has to be connected to electrical power source. The rapid evolu- tion of software development platforms brings in new features on a daily basis but atthe same time seems to be rather vulnerable and suffers from infantile problems, which in many cases are easy to handle but nonetheless remain annoying and need to be addressed. 9.8 Mobile User Interface Issues ‘The small form factor of mobile computing devices and their usage pattern by mobile users give rise to special mobile user interfaces requirements, both func- tional and non-functional. Functional requirements are directly related to user needs for the intended application. Non-funetional requirements are introduced not by user needs but as constraints posed by the employed technologies and stan- dards, as well as by special requirements related to the application field, e.g, secu- rity, interference, etc. ‘When designing user interfaces for small factor devices a common pitfall is to attempt to fit within a single small screen all the features that are expected to be available on larger screens of desktop applications. Instead, one should carefully consider the typical user interface design patterns that are applicable to the smaller screen of PDAs and produce a dedicated mobile user interface design. Indeed, itis not practical to seek to make available all the functions intended for the mobile user within a single high-level overall user interface, Smart interface design can ‘make them indirectly available, while working within the constraints of the small sereen, Table 9.2 summarises typical screen design characteristics, whilst Table 9.3 summarises application navigation options for the same design patterns (Bal- lard 2007), Screen design for mobile devices seeks to overcome the small form factor limi tations by embedding enhanced browsing and navigation options in smart user in- terface designs. From simple list and table-based selection to menu and tab-based. selection, with a limited number of clicks, touches or stylus integration these de- signs offers much greater functionality than would have otherwise been available ‘on such small screens. ‘Table 9.2 Mobile user interface design patterns Uldesign Design Applicability Use Rationale patterns List Verical, text Serolland select Web-based Tatitive; avoids wrapping, simple devices with applications side ars and small sereea: up tables; works on to two columas most devices Table 92 (continued) “Mobile Devices and Services 241 Ul design Design Applicability Use Rationale patterns Table Includes all able Stylus-based Not suitable for Simple and features devices without ott. keys: good when icons are used as table cells Location selection Set usage context All devices Useful when Can support (eg. shop floor;

    You might also like