Students: Ben Standish and Steve Sullivan
Faculty Advisors: Mark Austin and John Baras.
Date: September 2002 -- December 2003.

TABLE OF CONTENTS

1. Introduction
   

2. Use Case Model
   

3. System Modeling and Analysis
   Topics: High-Level Requirements; System Structure; State Chart Diagram for Tag Behavior

4. Requirements and Specifications
   Topics: Requirements Traceability Matrix

5. System Tradeoff Analysis
   Topics: Multivariable Analysis with CPLEX; Input file for CPLEX; CPLEX Results and Analysis; Choosing the Optimal Design.

6. System Validation and Verification
   Topics: Verification of Design Requirements, Verification Task Plan.

7. References
   

8. Appendix A - Verification Requirements
   

The goal of this project is to apply systems engineering principles for the requirements development, tradeoff analysis, and verification and validation of an automated inventory tracking system.

This system shall contain RF tags designed to track material movements into and out of warehouses. The system will be based on an automated data acquisition backbone which will include tags, transmitters, receivers, pre processor, and a database to reduce inventory management time. An automated tracking system is very useful today with the move toward improving operating efficiency, at all levels, of those industries providing services and goods. In many instances, companies are utilizing extensive indirect dollars to inventory and track materials moving into and out of storage. However, by automating the system, dollars can be saved and logistic personnel can have near real time inventories of the warehouses they manage.

Figure 1. Logistic Tracking System Schematic

Most likely, business expansion will drive the economic development and choice of technology for this system. For example, as a company increases its warehouse inventory during company growth, either additional people will be needed to track inventory or an automated system that can easily handle expansion will need to be installed. Obviously, the latter is more desirable due to decreased life cycle costs, as long as the technology utilized is feasible. Therefore, the tags (which will be purchased in large quantities) and transceivers must be inexpensive. With the use of preexisting technology, or commercial off-the-shelf (COTS) items, this system can be developed at a low cost to the customer.

Figure 1 illustrates the conceptual configuration of our warehouse based inventory tracking system. Programmable radio frequency (RF) transmitting tags, encoded with tracking information such as quantity and type, would be attached to bundled items prior to warehouse storage. The tags, which can be programmed by a warehouse worker using a handheld device, would then communicate with RF control units and extenders to notify a data base of the pallet contents, quantity and presence, for instance. From the data stored and transmitted by the tags, the database will be able to track overall presence, quantity, type, and age of material stored in the warehouse.

For the purposes of requirements elicitation, tradeoff analysis, verification and validation, this project will be focused on the tag portion of the inventory tracking system. In order to convey the understanding of the overall system operation, the following models and diagrams will encompass total system behavior. However, requirements synthesis and breakdown will begin to focus on the tag until reaching the tradeoff analysis, which will focus solely on tag design and selection.

Upon completion of the tradeoff analysis, verification and validation is the final process for the RF tag design. In order to assure the tag meets the stakeholder requirements, a verification plan has been designed which traces the test plan methodology to the tag specifications. The final section of this project will center on the specification traceability, development of verification requirements, and the introduction of a task plan for the RF tag.

The primary function of the system is to track materials and provide materials data that can be used to improve efficiency, reduce costs, and reduce errors in the process of shipping and storing materials. The primary actors or end users of this system are the warehouse operator (WrhsOpr) and the logistics officer (LogOfcr). A secondary actor would be the physical environment such as ambient conditions inside and outside a warehouse, or obstructions that block the transmission of RF waves. Upon analysis of the use cases shows that Track Movement is a concrete use case because a primary actor, WrhsOpr, participates directly in its implementation. However, the Database Update and Query use cases appear to be more abstract. Even though the LogOfcr interfaces with the system to generate a database query, he participates very little in the actual querying process. The LogOfcr is involved at the beginning to initiate the query, and at the end to use the data results generated by the query. Similarly, and to an even greater extent, the Database Update use case can be initiated and carried out without any primary actor participation. The real interface with the Query and Update use cases comes when the LogOfcr or WrhsOpr access the actual data that is produced. Therefore, the use case diagram contains two concrete use cases Track Movement and Access Data. Database Update and Query are abstract parts of the Access Data use case. Figure 2 illustrates the initial use case diagram.

Figure 2. Initial Use Case Diagram for Material Tracking System

When a customer determines the need for a developmental system, those needs are generally conveyed via high level requirements. Often ambiguous and general, an overall system or subsystem could not be developed from these initial system requirements. However, they do provide insight into the customers needs. Through the use of system modeling (i.e. use case diagramming, FFBD, and statecharts), the high level requirements can be broken-down and defined by low level requirements. These low level requirements will define the subsystems, provide the basis for specifications which define the requirements quantitatively, and, in the end provide traceability back to the customer's system need.

For the purposes of this study and inability to tackle the entire logistics tracking system, we will further extract the tag subsystem for definition, analysis, and tradeoff, in order to provide the most feasible solution to tag development for use with the entire tracking system.

High-Level Requirements

The initial high-level requirements are as follows:

1.0 Ability to automatically track materials

1.1 The material tracking system must be able to track all tagged materials within the 10,000ft2 warehouse.

1.2 The material tracking system must be able to log materials moving into and out of the warehouse.

1.3 The material tracking system must be able to function in an industrial warehouse environment.

1.4 The material tracking system must be able to populate a logistic database with all materials in the warehouse.

1.5 The material tracking system must provide a graphical user interface and portable logging system for use by warehouse workers.

1.6 The material tracking system must be able to automatically track materials and rapidly populate the logistics database.

1.7 The material tracking system shall be able to track no less than 500,000 tags simultaneously.

1.8 The tags must be able to transmit and receive signals for tracking which must not be diminished by dense storage of materials.

1.9 The material tracking system must be able to communicate via 10/100 Ethernet port.

System Structure

Figure 3 illustrates the static systems structure of the entire inventory tracking system. The diagram shows the connectivity of each subsystem in the creation of the complete system. As you can see, the tag is a critical subsystems as it communicates with the transceivers to populate the logistics database for tracking. As a result, the required functionality of the tag makes it a complex subsystem in itself, containing part such as a microcontroller, memory, an antenna, and a case, to name a few. To further complicate the scenario, each part within this subsystem has a range of potential attributes such as signal- to-noise ratio, power, gain, life (battery), range, and frequency, for example. Therefore, in development of the tag, a tradeoff analysis will be necessary to optimize the subsystem performance.

Figure 3. Tracking System (Local) Static Structure Model

In order to prepare for design optimization through tradeoff, we will establish the subsystem behavior, to be followed by development of the low level requirements and specifications.

State Chart Diagram for Tag Behavior

The purpose of this section is to provide a clearer picture of how the tracking system is to behave, and how its components and sub-systems can be fit together to form an integrated, fully functional inventory tracking system. To elaborate on the textual use cases, statecharts are used to model system behavior. They show the various pathways, or flows of events, that can be traced through the system behavior. Statechart diagrams are used to illustrate behavior for more complex sequences of events that would otherwise be difficult to show in an activity diagram alone.

The functionality and behavior of the tag subsystem is critical. Many of the other system components can potentially be off the shelf devices, such as the LogProc, GUI, RF Transceiver, etc., but the tag will be a custom design. The tags ability to retain and communicate data in all anticipated scenarios must be fully understood in order to properly specify the tag's performance characteristics. The tags behavior is best described by a statechart diagram, which is presented below in Figure 4.

Figure 4. Statechart Diagram for Tag Behavior

The high level requirements, which are very general statements describing the customers use/need for the system, are then defined more specifically. The results are low level requirements which are traceable to the system objects and functional performance.

1.0 The tag shall use proven technology to store and pass data between system devices in a predicable and repeatable manner.

1.1 Tags shall be capable of wireless, mid-range (at least ___ meters) radio- frequency communications.

1.1.1 The Tag shall communicate with transceivers mounted in a warehouse.
1.1.2 The tag shall communicate with manual tag programmers.
1.1.3 Antenna design shall be capable of sending and receiving radio frequency (RF) signals in a hemispherical pattern with sufficient gain and directivity to communicate at a maximum range of one mile.
1.1.4 The antenna design shall fit inside the tag enclosure and occupy a volume of no greater than 0.5 in3.
1.1.5 The Transponder RF signal bandwidth shall be ____ GHz.
1.1.6 The Transponder RF carrier frequency shall be 2.45 GHz, and shall conform to IEEE 802.11 standard for wireless data.
1.1.7 The Transponder signal-to-noise ratio (S/N) shall be at least ____.
1.1.8 The Transponder shall be capable of modulating/demodulating radio frequency signals using a known modulating technique, suitable for transmission through air.

1.2 Tags shall be capable of being programmed with a unique I.D. number, type of material, quantity, destination, and time/date information.

1.2.1 The microcontroller shall have at least 1 MB of memory for tag and program data storage, and 512 kB of RAM memory.
1.2.2 The microcontroller shall utilize non-volatile memory to store data and must be reprogrammable a minimum of 100,000 times.
1.2.3 The microcontroller shall have a 16-bit bus/memory structure.

1.3 The microcontroller shall have a clock frequency that is compatible with the signal processing speed of the RF Transponder.

1.4 The microcontroller shall have compiler/assembler software that will translate code written in a high level language.

1.4.1 The compiler/assembler shall translate C++ into binary code that can be downloaded and executed by the microcontroller.
1.4.2 The software shall have a functional debugger.

1.5 Tag shall have power consumption less than ___mW when in operating mode, and 5mW when in sleep mode.

1.5.1 The power supply shall contain a high power-to-weight ratio battery with sufficient amp-hour rating to operate the tag for at least 5 years, at a 0.5% average duty cycle per 24 hr. period.
1.5.2 The battery physical size shall be no greater than 0.75 in3.
1.5.3 The power supply shall have a regulated output voltage between 4.6V and 5V.
1.5.4 When the power supply output voltage drops below 4.6V (threshold voltage) the power supply must send a trouble signal to the microcontroller (mcu).

1.5.4.1 The mcu shall output a fault signal that is transmitted by the RF Transponder until a "fault signal received" signal is sent back to the tag from the Logistics Processor.
1.5.4.2 The mcu shall trigger a flashing "Fault" LED and go into sleep mode, upon receiving a "fault signal received" signal.

1.6 Tags shall be housed in a waterproof enclosure.

1.7 Weight of Tag shall not exceed 6 oz.

1.8 Tag dimensions shall not exceed (4" x 4" x 1").

1.9 The Tag shall cost no more than $___ per tag to produce.

Requirements Traceability Matrix

To develop a detailed requirements list for the Inventory Tracking System, the high level requirements must be broken down into subsystem and component level requirements that are useful to the design engineer. The low level requirements must contain details about subsystem interfaces, constraints such as size and power consumption, performance requirements, and details that are traceable to the specific system architecture. The subsystem design engineer will use this information to develop components that will integrate with other subsystems to form a cohesive system functioning to meet the needs of the stakeholders. Figure 5 illustrates the tag requirements traceability.

Note. B = Behavior, S = Structure, F = Functional, P = Performance, C = Constraint

In design and specification of the tag subsystem, it is necessary to consider multiple design possibilities and their interrelationships. For the complex problem of the tag subsystem development, a multi-objective optimization is necessary. Due to the multiple subsystem constituents, and varying specification ranges, as described under the system structure heading, tradeoff is necessary to optimize performance variables and cost. The following section describes our tradeoff analysis, aided by the use of CPLEX®, conducted in order to find optimal design parameters.

Multivariable Analysis with CPLEX

The following performance metrics, equations, and decision variables were used to perform a trade-off analysis of the Tag subsystem:

Decision Variables

1. x₁ = Ptrans (dBm) – Tag transmit power

2. x₂ = Gant (dBm) – Antenna Gain

3. x₃ = RANGE (meters) – The physical distance, over which, a tag can successfully communicate with a Tag Reader.

4. x₄ = BW (dBm) – Bandwidth consumed by the Tag RF channels, which is dependent upon the modulation technique.

5. x₅ = SNR (dBm) – Signal-To-Noise Ratio, related to the bandwidth and Tag transmit power.

6. x₆ = -Prec (dBm) – Transponder receive power

7. x₇ through x₁₂ = Boolean operators

Design Objectives

1. Minimize Cost
   

   The tag was divided into major components, and a scalar cost figure was given to each component that reflects the relative cost impact each component has on the Tag subsystem total cost:

   Total Cost = 0.2 x ₁ + 0.3 x ₂ + 0.25 x₄ + 0.05 x₅ + 0.25 x₆

2. Minimize Tag transmit power (represented by x ₁)
   

   The tag was divided into major components, and a scalar cost figure Because the Tag is battery operated, the power required to transmit a detectable RF signal at a given range will have a large effect on battery life, required antenna gain, RF signal range, Tag Reader quantity and placement, and of course cost.

3. Maximize Range (represented by x ₃ )
   

   A greater transmit range can allow tags at remote locations to be more easily read, potentially lowering the quantity of tag readers needed. Increased range adds considerable cost, as it requires greater transmit power and more efficient antenna designs.

Design Constraints

Performance of the system is constrained as follows:

C1   x₁ + 2 x₂ - x₃ + x₆ = 40.22 (Link Budget Equation)

C2   x₄ + x₅ + x₆ = 133.22   (Equation relating BW, SNR, Noise Figure, and Prec)

C3   60 x₁₂ + 57 x₇ + 57 x₈ + 55.2 x₉ + 54 x₁₀ + 54 x₁₁ - x₄ = 0

C4   13.4 x₁₂ + 23.1 x₇ + 13.5 x₈ + 18.8 x₉ + 24.4 x₁₀ + 20.5 x₁₁ - x₅ = 0   (Boolean OR operation for choosing SNR)

C5   x₇ + x₈ + x₉ + x₁₀ + x₁₁ + x₁₂ = 1   (Boolean OR operation – Only one variable from the range x₇ through x₁₂ can be one, the others must be zero)

With:

    0 = x1 = 30		0 = x2 = 6		30 = x3		27.7 = x6 = 90
    0 = x7 = 1		0 = x8 = 1		0 = x9 = 1		0 = x10 = 1
    0 = x11 = 1		0 = x12 = 1

Input file for CPLEX

The CPLEX input file is as follows:

   Minimize

   0.2 x1 + 0.3 x2 + 0.25 x4 + 0.05 x5 + 0.25 x6
 
   subject to
 
   x1 + 2 x2 - x3 + x6 = 40.22
 
   x4 + x5 + x6 = 133.22
 
   60 x12 + 57 x7 + 57 x8 + 55.2 x9 + 54 x10 + 54 x11 - x4 = 0
 
   13.4 x12 + 23.1 x7 + 13.5 x8 + 18.8 x9 + 24.4 x10 + 20.5 x11 - x5 = 0
 
   x7 + x8 + x9 + x10 + x11 + x12 = 1
 
   bounds
 
   0 <= x1 <= 30
   0 <= x2 <= 6
   30 <= x3
   27.7 <= x6 <= 90
   0 <= x7 <= 1
   0 <= x8 <= 1
   0 <= x9 <= 1
   0 <= x10 <= 1
   0 <= x11 <= 1
   0 <= x12 <= 1
 
   generals
 
   x7 x8 x9 x10 x11 x12
 
   end

CPLEX Results

The preceding equations and variables were entered into a CPLEX input file and several runs of the file were made. To aid in the multi-criteria analysis, the bounds on the two performance metrics Ptrans and RANGE were adjusted for each CPLEX run to minimize and maximize the metrics respectively, while allowing CPLEX to minimize the cost function. The results of the CPLEX runs, eleven in all, are tabulated below.

Analysis of CPLEX Results (Identification of Pareto Points)

The following three figures show graphically, the relationship between the three performance metrics COST, RANGE, and Ptrans. The purpose of the multi-criteria analysis is to identify the set of optimal solutions that exist for these metrics, subject to the constraint equations and the bounds that are placed on the decision variables. The set of optimal solutions represents points on the three-dimensional trade-off surface, which are called Pareto points. The definition of a Pareto point, as described in [2] is:

"A Pareto point is one where any improvement in one design objective can only take place at the expense of at least one other design objective. Therefore, it can be stated that no Pareto point is objectively better than another. The choice of one versus another can only be made on the basis of subjective human judgment (e.g., decision or preference)."

Turning to Figure 6 it appears, based on this definition, that all eleven points are Pareto points. A comparison between any two points shows that an improvement in any one metric, whether it is cost, range, or transmit power, will yield a trade-off in at least one other metric. This is true for all eleven points, so it could be argued that any one of the eleven points represents an acceptable design. However, to the system designers this is not completely satisfactory. Although CPLEX generates solutions that are numerically (objectively) optimized, there is still a subjective and qualitative element that must be applied to the analysis, in order to choose the optimal solution for this particular design.

Figure 7. Plot of Range vs. Transmit Power

Figure 8. Plot of Cost vs. Transmit Power

Figure 9. Plot of Cost vs. Range

Choosing the Optimal Design

The table in Figure 6 shows the numeric changes that occur in the decision variables, as you move from point to point in the design space. The row for Point 6 is highlighted because it is of particular interest in this analysis. Point 6 is also circled in red on Figure 7, 8, and 9. Referring to Point 6 in Figure 7, if we move from Point 6 to any other point on the graph, there is an increase in transmit power, this is true only for Point 6.

An analysis of Figures 7 and 8 show in general two clusters of points. Cluster #1 (Points 1 through 5) are the design solutions that represent lower cost, lower range, higher transmit power alternatives. Cluster #2 (Points 6 through 11) are the design solutions that represent a higher first-cost, but have greater range and lower transmit power characteristics. Because the tag is a battery-operated device, power consumption is a major concern, and in this case represents a greater challenge for the tag designers than first-cost. The tags must function in the field for years without changing the batteries. It is very reasonable to argue that a nominal increase in first cost will greatly outweigh the incurred cost of battery maintenance and the frequent loss of inventory data due to premature tag power failures. Due to the considerable impact that the transmit power metric has on the Tag Subsystem design, the Cluster #1 points can be eliminated as potential design solutions.

A fortunate consequence of retaining Cluster #2 is that it represents the higher transmit- range solutions, in addition to requiring less transmit power. Range is almost as important as transmit power in this case, and again, makes the Cluster #2 solutions more desirable.

Earlier it was mentioned that Point 6 was of particular interest in this analysis. The most obvious reason is that Point 6 is a member of Cluster #2, making it desirable. In addition it was mentioned earlier that Point 6 is also the lowest transmit power solution. Considering that the priority ranking of the three performance metrics is, in this case:

1. Minimize Transmit Power (Very Important)
2. Maximize Range (Important)
3. Minimize First-Cost (Moderately Important)

We find that Point 6 has the best (lowest) transmit power, adequate range capability, and is the lowest cost solution contained in the Cluster #2 solution set. Therefore, the choice for this design is Point 6.

Tradeoff Conclusion

A two-part, trade-off analysis has been performed to find an optimal solution for a design that contains multiple, conflicting design criteria. The first part, Multi-Criteria Optimization, was performed using CPLEX to find a set of potential design solutions. The solutions were then analyzed to identify Pareto points, which lie on the three-dimensional trade-off surface. The second part involved the subjective and qualitative analysis of the Pareto solutions to choose the most desirable solution for this particular design. In this case Point 6 was chosen. The final design specifications that were not yet listed in the design specification are listed below, with the blank values filled in:

1.1 Tags shall be capable of wireless, mid-range (at least 193 meters) radio- frequency communications.

1.1.5
The Transponder RF signal bandwidth shall be less than or equal to 500 kHz.

1.1.6
The Transponder RF carrier frequency shall be 2.45 GHz, and shall conform to IEEE 802.11 standard for wireless data.

1.1.7
The Transponder signal-to-noise ratio (S/N) shall be at least 13.5 dB.

1.1.8
The Transponder shall be capable of modulating/demodulating radio frequency signals using 4-state Phase Shift Keying (PSK-4).

1.5 Tag shall have power consumption less than or equal to 13.34 mW when in operating mode, and 5mW when in sleep mode.

1.10 The Tag shall cost no more than $34.66 per tag to produce.

Referring to Figure 10, the V-Model of systems development, the process of requirements flow-down involves decomposition of the high-level stakeholder requirements into detailed subsystem and component specifications, which are used by component and subsystem designers to produce integral parts of a system from the bottom up. The task of system verification is to prove the system functionality concurrently as the design is trans-formed into functional component, module, subsystem, and system level objects and assemblies. At the highest level of verification, the system is tested against the stakeholder requirements, which is called validation. Once validation is complete, the system can be fully commissioned and turned over to its users.

Figure 10. V-Model of Systems Development

Verification of Design Requirements

A verification plan for the tag subsystem will insure that the requirements listed in Figure 5 are verified, and the tag is properly designed for use within the inventory tracking system. Each design requirement listed in Figure 5 must have at least one verification requirement that can be traced to it. In some cases several verification requirements are needed to properly verify one design requirement. The table of verification requirements is listed in Appendix A. A verification traceability matrix is used to document the traceability between the various design and verification requirements. The verification requirements are then organized into tasks based on the type of verification (test, analysis, examination, etc.) and the level (component, module, subsystem, etc.). Ultimately, the tasks are further organized into a task plan to expedite the verification process. As shown in Figure 11, the process of deriving the task plan involves all levels of system development

Figure 11. Relationship Diagram for Verification Task Plan Development

To create a task plan, The verification requirements (Appendix A) were matched to the design requirements using a verification traceability matrix, which is shown in Figure- 12 below. This matrix also includes the verification task numbers (VTN) used to create the task plan, for this project a separate compliance matrix was not needed. Figure 12 shows that all design requirements have traceability to at least one verification paragraph. VTN's were assigned to verification paragraphs starting with lower level verification and proceeding in general towards system level and stakeholder validation requirements.

Figure 12. Verification Traceability Matrix Including Tasks

Verification Task Plan

The task plan is simply a table listing the VTN's in ascending order, with a description of each verification procedure. The task plan for verifying the tag subsystem is shown in Figure 13. It is not marked in the figure, but some tasks can be carried out concurrently, such as Task 1 (Antenna) and Task 5 (Battery/Power supply) because these components function independently within the Tag subsystem. Other tasks such as Task 3 (RF Transponder) and Task 4 ( RF Comm. Module/Microcontroller) must be performed in order because the RF Transponder must function properly before it is assembled into the RF Comm. Module and interfaced with the Microcontroller.

Figure 13. Verification Task Plan

1. Freeman, Roger L., "Radio System Design for Telecommunications," John Wiley and Sons, Inc., Second Edition, 1997.
2. Messac, A., and Mattson, C. A., "Generating Well-Distributed Sets of Pareto Points for Engineering Design Using Physical Programming," Optimization and Engineering, Kluwer Publishers, Vol. 3, Issue 4, pp. 431-450, December 2002.
3. ISO/IEC Std. 18000-4 CD.

Developed by Ben Standish and Steven Sullivan, Fall Semester 2003
Reformatted and slightly modified by Mark Austin, December 2003
Copyright © 2003, Ben Standish, Steve Sullivan, John Baras and Mark Austin. All rights reserved.