RTLS implementing

Implementing a real-time locating system into operational environment is the challenging task to prepare some standardized equipment for deployment and tailoring the applications to the special needs of an operator on a single site of operation.
This page on implementing real-time locating systems refers to RTLS according to ISO/IEC 247340 . Please get informed also with the operational task section of the RTLS page.
Preparations
To make RTLS operational, a careful preparatory process of deployment is required. This has aspects with staff and aspects with planning the infrastructure, finally covering the aspects of the operational assessment in coincidence with the installation.
Deciding upon a definitive choice
The operator of any RTLS solution must decide for a distinct systems layout. Hence he decides upon a special choice, that does no allow for the features of any other solution. This is a requirement that cannot be fulfilled by the supplier.
An initial selection must be made between a commonly available satellite approach, that requires open air or at least sufficient signal reception for satellite and mobile communications or any terrestrial approach that requires some infrastructure deployment to become operable.
A decision then includes a special choice e.g. for the following features:
* maximal speed to be covered with the moving transponders
* minimum error achievable with the selected frequency
* average latency time to get a location measured or a position fixed
* inclusion of orientation in any position or motion to recognize direction
* concatenation with identification other but that of the tag located
Conditions of fuzzy operation
A prior requirement must be filfilled without restrictions and cannot be separated from locating: The data of identity and the data on location must be concatenated preventing from any mixing up of identities.
The measuring of physical data in a real time process however is always connected with some fuzzy reception of the data set describing physics, as there may be
* a time lag between the single measures taken
* an over determined system of determining equations
* an imprecise set of measurements
* heavy bias to the measurements due to multi path propagations
* a multiplicity of other ambiguities and erratics.
The four laterations required to obtain a single fix in three dimension (3D space) is taken sequentially with decentralized or autonomous systems while there is no synchronized or just calibrated measuring. Such erratic measurement is not avoidable in improvements of physics qualities or any technical means, but by precautions of discipline and considerations of operational context. And imprecise measurement must not affect proper operation, but has to be taken into account as the standard condition. Beyond, the missing of required continuity has to be considered when applying classical filtering methods.
The motives of deciding should be noted by each party to defend the choice later. An escape from traditional thrive for precision is described in fuzzy locating.
Binding the parties involved to conditions of acceptance
The requirements document agreed upon between the purchases and the supplier will bind both parties to physical qualities and to operational quantities. Neither the supplier nor the purchases should not make the mistake just to specify physical quantities, as these must not reflect a proper depiction of the operational needs. A very precise solution might be too slow and a very fast solution might be too imprecise. However, a solution too fast and too precise will be too expensive anyhow.
Buying in to the solution
Innovative Technology and applied technical equipment is often subject of adverse feelings of the people involved. This may lead to a queer judgment of suitability. The protagonists and proponents may cultivate an atmosphere of advocating free from feedback. The antagonists and resistance fighters may do quite the opposite. Careful information policy is required to prevent from such fighting. It is a mandatory requirement to make all parties buy in to the solution in full conscience of the problems with and without RTLS.
Economizing the solution
Many approaches from interested parties are initially monovalent, asking for e.g.
* patient security
* asset tracking
* process optimization
* staff allocation
None of these applications solely pays for the infrastructure requirements. Only conjunstion of at least two aspects covered will pay back for the investment. Prospective calculations of an ROI with aspects of security only must be taken with care.
There is no escape, all aspects may contribute to a sound deployment, but not all of them at the same time. It is required that the management and the staff represéntatives do not tangle the interests and work hard to meet in a mutual understanding of a phased introduction of the new system. And there is evidence, that in the end, all aspects will at least be touched, if not fully covered.
A possible strategy is to address the weak targets first: Assets and patients.
Planning considerations
Planning may extend to mapping the propagation conditions in the operational area. Such solutions are available, to compensate partially for a missing travel time metering, e, g, when RSSI is the only means to range.
But even in TOA or TDOA systems designs, the assessment of propagation is required at least to place the anchor nodes advantageously. Regular patterns for anchor point deployment might please the aesthetic sense of planners, but must not cope with technical needs.
Implementing a new RTLS for operations
The implementing of any RTLS must be tailored to the specific needs in the operational area and for the support of users of the obtained information. There is no standard solution to serve special requirements without tailoring. That does not require entirely new development for each implementing, but at least some sound parametrising for such implementing.
For the appropriate set of parameters for the implementation the purchaser must take into account the following:
* General operational conditions, especially
* Power supply for portable units
* Ambient conditions, especially
* Networking conditions
* Features of systems dynamics
* Features of operational populations
* Requirements for communications of operational data
etc.
This bouquet of considerations will lead to a careful phasing of the implementing process. Above all steps the specifying of the various layers and for the diverse aspects of system layout is the key to success.
RTLS infrastructure considerations
Normally, an RTLS according to the definitions given with ISO 24730-1 is composed of either wired anchor nodes or of all wireless nodes largely autonomous communicating to each other. For an RTLS solution to interface to other networks is not mandatory, but for advantage of the using application, any RTLS has at least one link to another network to enable access to data bases. However, for locating an object or a person, some reference requirements must be fulfilled, where it does not require any further infrastructures.
Some common features of RTLS infrastructure requirements may be:
* Database with the coordinates of the deployed reference points
* Database with the addresses of the reference points and other nodes
* Server function for distributing and collecting operational data
* Server function to supply display functions in other than the moving nodes
Infrastructure prerequisites for an RTLS
Some RTLS systems in the market provide excellent accuracy for locating moving nodes, i.e. the objects or individuals bearing an RTLS locator. However, a fair comparison of systems should take into account, at which expense such accuracy is obtained. Drilling holes in the floor, wiring walls with copper or spinning densely meshed nets of reference nodes under ceilings may appear as reasonable for steady implementation, but this is contradictory to any rapid deployment requirements.
However, the known and qualified approaches with relatively low effort in infrastructures are:
* Using a GNSS infrastructure in open air and a terrestrial network for mobile communications (e.g. GSM)
* Using a fiber wired network of incidentally wireless anchor vertices
* Using a terrestrial network for ad hoc communications (e.g. IEEE 802.15.4aCSS or IEEE 802.15.4aUWB)
* Using active mobile nodes and receivers under a segregation by confinements that block communications (e.g. by walls)
Concerning international standards of ISO/IEC 19762-5 and ISO/IEC 24730-x the latter alternative is not an RTLS systems according to the standardized definition, but works well under the constraints of confinements.
Choice of board and chip integration for an RTLS
RTLS is a mature technology. However, the quantities in production are still on the rise. This rules also the integrating of functions with chips. Most of the solutions offered are well contained hardware developments, however the degree of integration varies. This is at stake for the cost of any deployment. The better the integration is elaborated, the lower the cost for the transponders will be. This applies as well to all types of transponders: For fixed mount operation, for personal carriage and for application to dead property. On the other hand, price is not the absolute measure, the balance between benefit and cost rules whether transponders are economized. However, chip integration as well rules the power consumption in operation. This again has to be balanced, as functions like active ranging always consume more power than just passive receiver operation.
Wireless access to any local RTLS implementation
Normally in advanced wireless communications systems, the communicating units on air are autonomous wireless nodes. That feature of autonomous operation describes the advantage that basically and beyond unconditionally required knowledge for direct addressing no administering is required.
An easy approach is unilateral broadcasting to start a polling process, but this invites unwanted parties. However, for exclusion of unauthorized third party nodes and inclusion of nodes for membership in a local network, at least some identification and some exchange on encryption is recommended to keep unauthorized intruders apart. Such enrollment procedures may be performed with any node that has the knowledge of accepted addresses, additional identification and passwords along with required encrypting. Otherwise any node would be able to interfere with the members of the network.
Lesser advanced systems may have limitations in the following aspects:
* Communications may be limited just to process locating and to exchange of location data sets
* Addressing is limited to exchange of any MAC addresses or even proprietary addressing concepts
* Identification may possibly be overwritten so that any node may change its system identity beyond MAC addressing
* Encryption may not be a feature foreseen for securing the communications
Such RTLS implementations do not comply with the referred standards according to ISO/IEC 24730.
RTLS and WLAN wireless coexistence considerations
Normally, any RTLS may use its specially designed set-up of channels in any available ISM wireless communications band. This applies either in the 2.45 GHz range or in the 5.8 GHz range. However, some aspects recommend the choice of a band and bandwidth that may support just the locating and some communications functionality beyond and without impact to other already existing infrastructures. There is an approach to an RTLS which is compatible with other users in the same ISM band and which is currently in the process of standardization. This approach is capable of locating and communicating in dense populations and with reasonable channel capacity: The proposal is under discussion in ISO/IEC DIS 24730-5 Information technology real-time locating systems (RTLS) Part 5. This standard proposal is taking the basing IEEE 802.15.4aCSS standard as a specification for communications (promoted through Nanotron Berlin, Germany, www.nanotron.de, and Orthotron, Seoul, Korea, www.orthotron.com) as a platform. This communications approach led with the manufacturing of Nanotron to an industrially designed chip-set (nanoNET NA5TR1) including a metering engine on the basis of symmetric TOA on a homogenous link. These chips are ready for implementing in general wireless systems as well as for RTLS implementation with making use of the WLAN channel scheme according to IEEE 802.11 and thus enabling proper coexistence of WLAN networking with RTLS locating in the very same area.
Anti-collision strategies with RTLS
The competing requests from any nodes in any ad hoc advanced network or any administered legacy network create collisions. The mandatory requirement is a proper strategy for avoiding collision or at least live with the competition and be effective. The basic issue for any RTLS implementation is the capability to provide metering beyond anti collision procedures. The secondary issue is to enable communication beyond metering. Both are tasks before coping with the population challenge.
The solution may not be just a deterministic approach.
Impact of population density with RTLS
Granularity of the RTLS deployment is not just a question of resolution and accuracy, but also a parameter for coexistence of adjacent vertices. The capability of an RTLS to cope with high density of nodes supersedes the accuracy requirement. In case of two RTLS node bearers adjacent to each other, the accuracy of locating each of both might degrade somewhat. But an effect that the locating function might fail due to close vicinity of two or more bearers should be taken as a hard disqualification criterion.
Power on the move
The option to locate an object implies the need to power the unit to be located on the move. This limits the available functions with the moving node. Despite the locating of vehicles there is no power line with moving persons or dead objects.
However, the production lots and the preparations to integrate functions with a processor platform limits the reach of battery. Consider the following nexus of constraints:
* Versatility of application defines communality of requirements
* Communality of requirements controls the quantity of sales
* Quantity of sales in units is proportional lot size in production
* Lot size in production defines the affordable degree of integration
* Degree of integration is somewhat proportional to power consumption
* Power consumption contradicts to battery weight
Generally, taking any actual design of cell net phones with an integrated GPS function as a comparable reference, the locating should be comparable in operational availability. But, this is the target for product development on mid term. Do not forget the design history in the last two decades to arrive at the functional complexity of cell net phones of today.
Locating engine
The locating engine is a part of an RTLS providing the computing of location from Measurements. Generic details see under Locating Engines.
Dynamics of locating with an RTLS
Generally with moving nodes the validity of location data is limited to the motion characteristics of the nodes
located. Hence the quality of the systems approach is related to the dynamics behavior of the respective systems
layout.
Latency times of RTLS
Users of wireless systems and of navigational aids will know in detail the effects of any obstacles to direct sight and any interference of more than two transmitters etc. The cardinal quality measure for any such condition is the latency time to cope with relocation of any object. Latency is the sum of times from request through reaction till availability of an answer with the requester.
The first proper locating with an RTLS should be ready for display in much less than a minutes time.
However, such quality metrics should be independent of any supporting system, as inertial measurements, track extrapolations or optical system aids. All of such options are welcome to improve an RTLS system performance, but they should not be taken into account when comparing different RTLS solutions.
Renewal of location data
Mobile nodes on the move may change their location without prior notice. They even may change their direction
without prior notice. Hence the quality of the location data has to take into account the dynamics of the motion
in terms of covered distance and of current angular velocity
Precision of locating
User requirements often start with precision. As an RTLS is an operational means and no gauging tool, this aspect must be carefully balanced between benefit and cost. Dealing static precision as a primary issue is just dumb, as an RTLS is designed for dynamic purposes. The key parameter is dynamic precision with respect to operational challenge. An RTLS solution properly supporting decisions on the move is the design aim. However, momentary locating errors may infer pretension of correctness all time.
Accuracy of guessed location
An excellent RTLS will serve the user with an accuracy in the range of his very own dimensions. That may be in the case of individuals an accuracy of about .5m or 2ft (area) down to 2m or 6ft (height). A reasonably good RTLS will serve the user with an accuracy not lesser than a multiplicity of his very own dimensions in the range of about 1.5m or 5ft (area) down to 4m or 12ft (height).
These error margins provide proper support for typical operational requirements:
* Concerning an application in logistics, the size of a pallet will be understood as a reasonable measure for accuracy, then the locating may distinguish between the left, middle or right pallet in a row of three.
* Concerning in an application in conferencing, the distance between persons in conversation will be understood as a reasonable measure for accuracy, thus the distinguishing between the searched person and his conversational partner (interlocutor) should be possible using straight vision.
* Concerning an application with vehicles, a sound RTLS will be capable to determine the position of one or the other vehicle. However, for manned vehicles, the straight vision of the driver may compensate for momentary degradation in locating service.
To obtain benefit with any RTLS implementation and with full deployment, the demand for high accuracy should not encumber the balance of cost and benefit. An RTLS will not replace a measurement subsystem for dynamic positioning or any topographic or geodesic metering.
Filtering
The essence of RTLS design beyond metering is filtering. As in all measuring systems, erroneous results superpose the wanted correct metering. This starts with noise, followed by statistical errors and ends in heavily threatening multi path propagation. There are several approaches possible to defeat these errors. Thriving for accuracy may be performed at the expense of resolution, of latency times till availability or of stability of the results.
How to overcome multi-path propagation
As outlined: Multipath propagation is ubiquitous with wireless transmission. There is no escape to prevent from multiple reception and resulting response to any transmission. Thus, for an RTLS the multipath propagation is a burden in the metering process. Therefore strategies to assess the response is indispensable. Such strategies apply in subsequent steps:
* Balancing metering and routing to ensure stable networking
* Multiple frequency transmission to share the problem
* Repetitive transmission to establish a sufficient statistics
* Reception and computing of more than just the strongest signals
* Well defined filtering to exclude erratically unbalanced measurement
* Strategic filtering to eliminate the longer paths via reflecting surfaces
* Estimating locations based on a well designed and consistent estimator
* Over-determined modeling to compensate for persistent false path returns
* Taking inherent dynamics of moving objects in to account
* Building tracks to compensate for singular false estimates
* Low Pass filtering the presentation to prevent from irritating the observer
* Presenting the results as a continuous flow of information to stimulate trust
* Assessing the flow of results and publishing a trust parameter
This list may be extended for the purpose of the operational task. Another escape is hybridization of the system to enable stronger start-up conditions and to provide supporting external sample points. Finally, the solution may not be just a deterministic approach.
RTLS mathematical modeling
Mathematical modeling is a prerequisite for an RTLS providing the computing of location from Measurements. Details see under Locating Engines. The other aspect is the mathematics based model of operation, addressing not the locating process, but the wrapping of the obtained coordinates with the operational context.
Applying RTLS for operations
To apply any RTLS system must address some requirement to make information available on the spot. It makes no sense to deploy any RTLS, when the Real-Time aspect does not drive the choice. In function, RTLS shows many resemblance to location based services of mobile phone networks. Such typical application may be
* Resource tracking with local distribution: Fork-lifts, pallets, cardboard-boxes, tools, machines
* Resource tracking in a protective manner: Objects without other privacy controls,
* Finding someone or something: Look-up a person by skill (doctor), by capability (disabilities), by quality (tool sets, handy machines etc.)
* Proximity-based actuation (push or pull) buddy finding (grouping), common profile matching (dating), staff management (convening) and resulting approaches
* Proximity-based notification (push or pull) fulfillment based upon proximity (sports, pass, toll), threat based upon track (perimeter protection, asset protection, service performance).
This list may be extended upon relevant requirements.
Roles in an RTLS implementation
An RTLS is not a radio detection and ranging system, but an autonomously operating and functionally cooperative system of basically equal nodes. Therefore there is no central scanner function nor any central processing instance nor any otherwise specialized RTLS node to receive, collect and compute data in the locating process for any other node beyond itself. As well there is no specialized higher qualified reader function nor any lower qualified and dumb beacon function.
Affiliating identification means
As the object to be located in logistics applications normally is the means to transport objects of varying identity, the identifying of the objects transported must coincide with the locating of the transporting means. This requires other independent systems deployed that shall cooperate with the RTLS support at least on information systems level.
Types of RTLS nodes
Basically any RTLS node shall obtain its own location in a cooperative measurement process and hence shall be capable to compute its own location with its own local resources. Additionally any other RTLS node shall be capable to receive the readily computed information from other nodes on location of these and further nodes. However, it may depend on the user requirements, which nodes will be excelled with signaling and display capabilities to support the defined operational tasks with the RTLS usage.
For the sake of an economized systems operation, the qualification of the wireless nodes in an RTLS implementation may differ to serve for distinct roles:
* a mesh of fix-mount RTLS reference nodes that just tells its identity and its location
* one each personally carried RTLS nodes to locate just the own location in a deployment of a multiplicity of mobile bearers
* a multiplicity of mobile objects tagged object wise with RTLS nodes to locate just any such unmanned and tagged object
* auxiliary option with the mobile RTLS nodes may be a local gateway function to serve other communications or further purpose processing units with location data
* application option with the fix-mount RTLS reference nodes is some wired power supply as well as any additional gateway function to forward any user information to and fro other network types transparently
Special fine tuning of network configurations may be possible to reduce the effort in resources tailored to the defined operational task. This may apply to permanent or temporal deployment as well as to the spatial distribution aiming at the line of sight conditions.
RTLS functionality for fixed nodes
A basic application for RTLS is the locating of nodes that normally should not move. Recurrently locating such nodes then simply confirms each node being in the determined place and in function. Such control may be achieved with active RFID as well as far as the resolution and stability for the actual location were of no importance. In any other case the 3D locating capability of RTLS with distance metering and locating engine trumps any RFID with bare RSSI capability.
RTLS complementarity
As far as budgeting is sound and design is balanced, an RTLS shall be aligned with other systems yet deployed.
RTLS complementarity to GNSS
The RTLS systems is just designed to provide a locating capability that may be:
* Firstly below the performance levels of satellite supported navigation (GNSS) regarding the reach of the covered area,
* Secondly right above the performance levels of satellite supported navigation (GNSS) regarding the latency times for locating and,
* Finally below the performance levels of satellite supported navigation (GNSS) regarding the accuracy of locating at low speed.
Normally, a user of an RTLS will be happy just to make use of the special functions of such system under any roofing or other confinement of operation. Additionally for any temporal deployment and for various operational conditions in open air, a hybrid solution may offer new versatility that will not be addressed by any purely satellite based function.
RTLS complementarity to RFID
For the user of any RFID labeling solution, there may be full satisfaction with identifying any object right in the scope of a manually held reader or with a fix-mount reader.
But in general, the complex event of identifying objects by means of any tool requires five, at least three data:
* What is the identity (serial number, type number, order number)
* What time is it at show-up of the object (clock time, calendar date)
* What is the direction of transport (where to in / out)
* Who identified the object (identity of reader and identity of operator, optionally)
* Where is the location to identify the object (location of the operator or just location of the reader, optionally)
The latter term of location is mostly neglected, when RFID readers are operated in confined environment. But, to satisfy the perpetuate desire for maximum reach, the question is important, where the object moved or stood in the moment of identifying it. However, this aspect will gain momentum in mid-term, as RFID is still mostly competing with bar-coding or 2D-coding. Besides the basic issues, the RTLS function generally requires power source on the object, so RTLS is not low-cost approach compared to labeling.
RTLS tracking and tracing
Tracking and tracing as concurrent or posterior computing of a trajectory covers the dynamic aspects of RTLS processing. The aim of ranging and locating is somewhat spontaneous, whereas the track or trace serves protracted interests of motion control.
Any information about momentary or temporary location of an object or a person may be collected to form a track or just to trace the instance or the individual. This in effect simply indicates the need to prove willful acceptance of services through the client under any RTLS control as deemed mandatory with any other location based service focusing individuals in wired or wireless networks. Unauthorised or otherwise impermissible tracking or tracing people with any technical means without such willful agreement will surely lead to dismissal of such services with the community affected.
RTLS for assisting planned operations versus RTLS for spontaneous locating
In industrial environment ordinary tasking covers fulfilment of planned and scheduled operations. Thus in industry any spontaneous locating will mostly not be the key interest. This coincides with the systematic weakness of real time locating, where knowledge about a steady motion may support well the computing of actual locus.
In any emergency or military environment however, there is a tendency to ask for spontaneous determining of an unknown locus, added with the requirement to perform as well on unknown territories or in confinements without any available maps. This appears as a completely different task concerning a supporting infrastructure.
A priori knowledge
Any RTLS system implementation will make use of a priori knowledge about locations of nodes, i.e. all available information about residing nodes or other nodes that disclose their positions. Such information may be just the address for networking and may comprise properly surveyed locations of reference nodes. This a priori knowledge is complimentary to all knowledge yet obtained in operation and compiled in tracks.
Tracking plots
Tracing is understood as elaboration off-line from recorded data and therefore never operated in real time. However, tracing makes use of data collected by means of tracking procedures. The actual tracking of nodes may contribute to collecting data for a trajectory in a data base and may then be presented in plots with underlain maps or drawings.
The anchor nodes in such tracking data sets may be
* model of network topology with topologic locations or a terrestrial or geodesic depiction with topographic locations (geo-locations) of residing nodes
* yet surveyed, metered or otherwise described locations
The trajectories of the traveling nodes may be recorded with a composite data set of locations of touched nodes and intermediate metering results.
Test specification
To be prepared to segregate corn and husk, there must be an appropriate specification form the very beginning. The interested operating party must set out its own demand. This may be answered by the offering manufacturing party with an appropriate test scenario, that will show the capabilities of the RTLS under test. However, the potential purchaser should stress his brain to identify the critical conditions, which he deems important for operational success, as there are:
* proper co-locating of directly adjacent objects, which is a very hard test to assess as well resolution and accuracy in conjunction with processing that prevents from interchange of positions
* sufficient stability, i.e. the track shall not make jumps that the tracked object would never perform
* sufficient precision, i.e. the reported position should absolutely and relatively be within the locating and ranging accuracy
* sufficient "hunting" quality, i.e. the track of the target should resemble the actual motion of the target
* sufficient speed, i.e.the tracking should show a delay that remains steady
* sufficient compatibility, i.e. systems operation shall not interfere with other systems nor crash in active environments
* sufficient robustness, i.e. systems operation shall not be limited to just and handful of moving nodes and shall be capable to let migrate additional moving nodes in as well as reference nodes fade out
RTLS presentation
RTLS shall be capable to derive locating on the fly, en passant, on the move and during performing. This results in some local display of vicinity and adjacencies. Presentation of results is the minimum output of any RTLS. This may be provided for moving entities or for any observer in the area of operations or apart from there.
The RTLS user gets the location of himself or of the objects under control
* either relatively with indication of distances, or
* dynamically with indication of distance changes, or
* absolutely with some accuracy in any defined grid of coordinates
The displaying of such information is performed visually on a map or in other graph. Alternatively the change of location may be indicated aurally with sound signals.
The applicability of RTLS for operational tasks is bound to the stability of the location depicted. It is neither an advantage to get a false information about location, which may appear in real time but with no real quality, nor may an unstable result support operations, i.e. spontaneous erratic jumps with every update, when the user cannot recognize the computed location as steady.
Technology polls
Having read till this passage, please feel free to contribute to a knowledge poll on RTLS with this link:
The survey is composed to show some alternative features for an RTLS in direct confrontation and not to put a burden on clarity of explanations here.
Communicating with other applications and systems
Beyond local presentation, the common requirement with locating RTLS nodes is some feedback to those monitoring systems and persons in charge that control the work orders. The RTLS system shall be capable to report locations of moving objects in conjunction with some data transfer to the destination of this reports. However, many of the systems designed in the past do not support such data transfer in the very same communications link. As with GPS operating just in downlink, normally data reporting is transmitted via Cellnet. This leads to the following alternatives for RTLS nodes:
* Locating is central and reporting is not defined
* Locating is just a downlink process, reporting is not included
* Locating is operated on one link and reporting requires an independent data link
* Locating and reporting are symmetric and integrated communications on one link
* Locating and reporting are symmetric and enable user defined communications on one link
The respective variety applies for the feedback with any type of moving RTLS nodes:
* Locating is central and no feedback is defined
* Locating is just local and feedback is not defined
* Locating and reporting are fully automatic, but feedback cannot be exploited
* Locating and subsequent reporting stimulate qualified feedback to the moving RTLS node
* Locating feeds back to order processing and order list is fed back in return and actually adapted
* Locating and subsequent reporting stimulate qualified feedback to the operator with the moving RTLS node
The scope and complexity of possible applications determine an unlimited plurality of options. The RTLS concept does not constrain respective operational designs.

Main Menu

See Also

Main Menu