Materiel Tracking System

The Materiel Tracking System is the integrated, networked system introduced in YE 36 by Star Army Logistics to monitor the movements and statuses of all equipment inventory throughout the Star Army of Yamatai.

Just as the Fleet as a whole uses Imperial Registry Numbers to keep track of ships and craft, Logistics uses MTS and the codes assigned to equipment to monitor the integrity of the Logistics process from delivery to dispersal. By consolidating the tracking system across the entire Star Army, Logistics is able to better leverage its existing commitment to automated systems and decrease point sources for errors. Where a logistics chain with a wide variety of inventory systems might require numerous digital or manual data handshakes, and so introduce the attendant failure points, MTS allows any facility - particularly Integrated Cargo Handling System capable warehouses - with network access or a the necessary data cache to seamlessly handle and transship any given item.

There are four core physical MTS components. They are modular and easily adaptable to different cargo handling systems, a critical feature given the wide variety of facilities operated under the Logistics aegis. The components are all produced for Logistics by the Ketsurui Zaibatsu, however the MTS standard is open source for Yamataian firms, so components built by other manufacturers may be incorporated.

The first and perhaps most important component, the MTS Labeler is used upon inducting an item into the system. This is typically done upon the first delivery of an acquisition by the supplier. The receiving process involves all equipment being sent through a labeler. Once fed an item, the labeler contacts the local server and receives a generated Tracking Code. From there, the labeler proceeds to apply a combination of three labeling options, depending on their suitability to the item. Further, the application of the labels is liberal, to ensure that even if one label failed many backups would remain. Once the labeler confirms the codes are in place, functioning, and correct, it passes the item along.

The labels take three forms, to provide options for all incoming materiel.

Any item that can handle it is given a micron scale laser etching of the tracking code in two-dimensional datamatrix form, with position and timing markings integral. The size is well within the constraints of an NH-33 Nekovalkyrja’s ability to see, though other species including the NH-31 Minkan require an intermediary device to see something that small.

For items whose function would be adversely affected by a laser etching, however small, a millimeter scale sticker carrying the optical code is applied. The sticker is applied with a small coating of Molecure Solution, both to allow extremely secure attachment and removal should the sticker interfere in the equipment’s operation.

Any item which can fit it is affixed with a millimeter scale RFID chip. The chip is extremely similar to the sticker, having the same size, bearing the optical code on its surface, and being secured with Molecure Solution. However, it is separate to allow different application density: it would be cost-prohibitive to distribute the RFID chips with the same frequency as the plain stickers. The chip functions passively, drawing energy from the interrogating EM field before emitting the encoded cleartext radio signature in return.

The scanner is a combined device, including both an optical sensor and EM scanner. The optical sensor quickly tracks over the surface of an item, detecting the varied optical labels across its surface and recording them. The EM scanner is a transceiver, emitting a low powered unidirectional EM field and detecting the energized return from the RFID chips. The scanner communicates wirelessly with the local server at extremely high speed, allowing extremely high throughput for inventory monitoring.

The local server is an integrated unit comprising of the Ke-T8-E3103 Computer Array and the Ke-T8-E3104 Communications Array used in Ke-T8 "Kuma" Multi-role Shuttle. While ostensibly overkill, particularly the communications function, the server unit has to be able to accept and process potentially huge numbers of code queries while simultaneously maintaining its local cache and communicating with the entire MTS network across Yamataian space. As such, the robust, capable, and highly reliable avionics set up from the Kuma was judged to provide the best existing platform to adapt. The unit is encased in an easily accessible electronics cabinet to allow for simplicity of maintenance. The computing core is loaded with a prepackaged adaptation of the standard Star Army Kessaku OS optimized for MTS database management. The server can be run in offline mode, only communicating with local devices, but the system is designed to function as a cohesive whole, with countless redundant copies of the full code database throughout the YSE.

A single server unit can serve an entire warehouse complex, though particularly high throughput facilities might see some system slowdown if only one server unit is left to run the entire operation. Once the server is installed and connected to PANTHEON, it reaches out to the MTS network and refreshes its code caches. Codes are pushed to local caches based on prepositioning forecasts and the likelihood of equipment coming into its region. Response time is markedly decreased if codes are already in the local cache, though the system still provides extremely fast turn around even if a network query is required.

With the server unit up and running, labelers and scanners can be wirelessly registered. While most facilities aside from acquisitions and disposal receiving do not have many labelers, all MTS facilities include at least one, in the unlikely event that a piece of equipment comes in that either lacks or has unreadable labels. Scanners can be used as handheld devices for inventory checks but are typical installed on automated load movers, particularly the Remote Load Handling Device. In that manner, MTS allows cargo movement to be almost entirely autonomous.

The server maintains a database of metadata associated with each code. This includes the specific information about the individual item, routing instructions, and record of all interaction with the system. Every time a labeler or scanner operates, it is required to callback to the server. The labeler always registers a new entry, but the scanner has several options. It can register an inventory check, arrival, departure, stocking, maintenance pause - should an item need to be pulled for repairs, or a restocking. The server appends this information to the metadata, along with the time and date, location, and user identity, whether that is a particular soldier using a handheld scanner or an autonomous system ID number for a load mover. As such, the MTS network maintains a comprehensive record of where each item is located and who or what put it there. This makes accidental loss virtually impossible and fraud extremely difficult.

In addition to using the dedicated physical components, authorized users and devices can load and utilize MTS data and applications. The most common use is for logistics personnel to check inventory without using a dedicated scanner. Any device capable of recording optical data can be used, with the right authorization, to query MTS code databases. Indeed, NH-33 personnel using their enhanced vision functionality can wirelessly query the system based on the data manually collected with their eyes. They can even cache limited sets of MTS code data for purely local work. This process is less efficient than the use of the dedicated components, but allows for alternative modes of operation.

Each individual item is assigned a unique code, with zero duplication in the system. Once a code has been registered it cannot be reissued, even to the same item should it need relabeling. Given the distributed nature of the MTS network, this ensures a very low probability of accidental duplication even among remote sites working in offline mode. In the event of a popup duplication from a previously offline site, the system automatically flags the items - identifying them by their metadata - and issues relabeling instructions. The items will all receive new codes and labels.

The codes themselves are not particularly interesting. Only a few digits have any meaning if examined without reference to the database.

Format: Condition - Class - Year - 60-Character Alphanumeric

Example: 2-G-35-1203488IOW501634789234058W972986512NOWQ63549234E50987BFG1234

The Condition is a number, 0, 1, 2, or 3, representing universal priority. Condition 0 items are emergency priority and Condition 1 items are high priority. These Conditions are reserved for truly dire circumstances and indicate special acquisitions that need to be dispatched to the Fleet immediately. Almost all equipment is Condition 2, representing normal priority. Even desperately needed items are assigned Condition 2 status assuming they are in the normal acquisition and inventory system. Their priority will be communicated by accelerated shipment orders rather than an intrinsic classification. Condition 3 items are undesirable and are to be removed from the system either by return to the original supplier, sale, or destruction. This Condition is typically only seen for items that are inoperable on delivery from the supplier or damaged equipment that has lost any previous labeling.

The class character is representative of the Star Army Supply Classification system. This generally outlines the sort of equipment in question and its rough importance.

The year designator is for the year the equipment was acquired, not the Type number associated with some products.

The purpose of the three identifiers at the start of the code is to allow logistics personnel to identify materiel in an emergency situation or in the event of an MTS failure. While the specific information and metadata about the item would not be available, certain information can be gleaned. For instance, a container coded 0-J-35-[…] would indicate an emergency priority medical supply acquired in Y.E. 35. Presumably it would be of great importance and logistics personnel would know to expedite its delivery. A container similarly coded 0-J-28-[…] would obviously be of lower importance, given its seven year old acquisition. However its Condition would single it out as odd and the personnel could report the container to the necessary authority.

Authored by Sean_ODuibher and approved by Nashoba on January 5, 2014¹⁾