Students: Ben Standish and Steve Sullivan
Faculty Advisors: Mark Austin and John Baras.
Date: September 2002 -- December 2003.
TABLE OF CONTENTS
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.
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.
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).
184.108.40.206 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.
220.127.116.11 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.
|1.0.||The tag shall use proven technology to store and pass inventory data between system devices in a predicable and repeatable manner.||Tag||Stakeholder|
|1.1.||Tags shall be capable of wireless, short-range (up to one mile) radio-frequency communications.||RF Comm. Module||System|
|1.1.1||The Tag shall communicate with transceivers in a typcial warehouse environment||RF Comm. Module||System|
|1.1.2||The tag shall communicate with manual tag programmers.||RF Comm. Module||System|
|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.||Antenna||B,P - Antenna Shape||Component|
|1.1.4||The antenna design shall fit inside the tag enclosure and occupy a volume of no greater than 0.5 in3.||Antenna||S,C - Antenna Shape, Size||Component low-level|
|1.1.5||The Transponder RF signal bandwidth shall be less than or equal to 500 kHz.||B,P - Bandwidth||Component|
|1.1.6||The Transponder RF carrier frequency shall be 2.45 GHz, and shall conform to IEEE 802.11 standard for wireless data.||Transponder||B,P - Carrier Frequency||Component|
|1.1.7||The Transponder signal-to-noise ratio (S/N) shall be at least 13.5 dB.||Transponder||B,P - Signal-To-Noise Ratio||Component|
|1.1.8||The Transponder shall be capable of modulating/demodulating radio frequency signals using using 4-state Phase Shift Keying (PSK-4).||Transponder||B,P - Modulating Technique||Component|
|1.2||Tags shall be capable of being programmed with a unique I.D. number, type of material, quantity, destination, and time/date information.||Micro-controller||B,F - Memory||Subsystem|
|1.2.1||The microcontroller shall have at least 512 kB of memory for tag and program data storage, and 256 kB of RAM memory.||Micro-controller||S,F - Memory Capacity||Component low-level|
|1.2.2||The microcontroller shall utilize non-volatile memory to store data and must be reprogrammable a minimum of 100,000 times.||Micro- controller||S,P - Programmability||Component low-level|
|1.2.3||The microcontroller shall have a 8-bit bus/memory structure.||Micro-controller||S,F - Memory Resolution, Quant. Error||Component low-level|
|1.3||The microcontroller shall have a clock frequency that is compatible with the signal processing speed of the RF Transponder.||Micro-controller||B,P - Proc. Speed, Scan Time||Component low-level|
|1.4||The microcontroller shall have compiler/assembler software that will translate code written in a high level language.||Micro-Controller||F - Programmability||Component|
|1.4.1||The microcontroller shall translate C++ into binary code that can be downloaded and executed by the microcontroller.||Micro-controller||F - Programmability||Component|
|1.4.2||The software shall have a functional debugger.||Micro-controller||F-Programmability||Component|
|1.5||Tag shall have power consumption less than 50mW when in operating mode, and 5mW when in sleep mode.||Tag||B,P - Power consumption||Subsystem|
|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.||Power Supply Battery||B,P - Power delivery||Component|
|1.5.2||The battery physical size shall be no greater than 0.75 in3.||Battery||S,C - Shape, Size||Component low-level|
|1.5.3||The power supply shall have a regulated output voltage between 4.6V and 5V.||Power Supply||B,P - Operating Voltage||Component|
|1.5.4||When the power supply output voltage drops below 4.6 V (threshold voltage) the power supply must send a trouble signal to the microcontroller (mcu).||Power-Supply, Micro-Controller Transponder||B - Self Diagnostics||Component|
|18.104.22.168||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.||Micro-Controller Transponder||B-Self Diagnostics||Component|
|22.214.171.124||The mcu shall trigger a flashing "Fault" LED and go into sleep mode, upon receiving a "fault signal received" signal.||Micro-controller||B - Self Diagnostics||Component|
|1.6||Tags shall be housed in a waterproof enclosure.||Tag||S,F - Durability||Subsystem|
|1.7||Weight of Tag shall not exceed 5 oz.||Tag||S,C - Weight||Subsystem|
|1.8||Tag dimensions shall not exceed (4" x 4" x 1").||Tag||S,C - Dimensions||Subsystem|
Figure 5. Requirements Traceability Matrix
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:
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 1 + 0.3 x 2 + 0.25 x4 + 0.05 x5 + 0.25 x6
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.
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.
Performance of the system is constrained as follows:
C1 x1 + 2 x2 - x3 + x6 = 40.22 (Link Budget Equation)
C2 x4 + x5 + x6 = 133.22 (Equation relating BW, SNR, Noise Figure, and Prec)
C3 60 x12 + 57 x7 + 57 x8 + 55.2 x9 + 54 x10 + 54 x11 - x4 = 0
C4 13.4 x12 + 23.1 x7 + 13.5 x8 + 18.8 x9 + 24.4 x10 + 20.5 x11 - x5 = 0 (Boolean OR operation for choosing SNR)
C5 x7 + x8 + x9 + x10 + x11 + x12 = 1 (Boolean OR operation Only one variable from the range x7 through x12 can be one, the others must be zero)
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
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.
Figure 6. Variable Output from CPLEX
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  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:
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.
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
Using a fully assembled Tag, RF Transponder, and laptop computer running
logistics tracking software, perform the following functions:
|V_1.1||Connect RF Comm. Module to a 5VDC power source. Perform the following tests: Sending - Connect input pin to a serial digital signal generator with 8-bit capability. Locate a known good RF signal receiver one mile from the RF Comm. Module. Transmit RF signal from comm module and record signal strength at RF receiver, signal must be at least - 27.7dBm. Receiving - Place a known good RF signal generator one mile from the RF Comm module and set signal generator to transmit a continuous signal at 13.34 mW EIRP. Use oscilliscope with printing capability to measure and record voltage signal at RF Comm. Module output pin.||Module|
Perform test 1 inside a building with concrete slab floor, steel frame, and
insulated metal siding. Mount RF Transcievers at 12' above finished floor.
Perform test 2 outdoors. Connect a data recorder to RF Transcievers to
verify communications between Tag and RF Transciever:
|V_1.1.2||Using a Manual Tag Programmer, perform the following operations on Tag: clear data, download data, upload data. Verify that uploaded data matches downloaded data. Use 8-bit data strings, fill tag memory to at least 256 kB on download test. Downloaded data shall include a sample I.D. number, contents of container, quantity, destination, and time/date information.||System|
|V_1.1.3||Perform a computer software simulation of selected antenna design, results must show sufficient gain and directivity to transmit a 13.34 dBm RF signal in a hemisperical pattern for a distance of one mile or less with signal strength of at least -27.7 dBm at any point within the one mile hemispherical coverage area.||Component|
|V_1.1.4||Verify in CAD software that selected antenna design will fit within tag enclosure and occupy no greater than 0.5 in3.||Component|
|V_1.1.5||Use a spectrum analyzer to verify that RF Transponder singal bandwidth is within 500 kHz. Record and time-stamp results, submit to systems engineers for project record.||Component|
|V_1.1.6||Use an oscilliscope to verify that RF Transponder carrier frequency is 2.45 GHz. Record carrier frequency and print oscilliscope display with time stamp, submit to systems engineers for project record.||Component|
|V_1.1.7||Use an oscilliscope to verify that RF Transponder signal-to-noise ratio (SNR) is at least 13.5 dB. For test use a white noise simulator, transmit at 5 dBm Record SNR and print oscilliscope display with time-stamp, submit to systems engineers for project record.||Component|
|V_1.1.8||Use an oscilliscope to verify that RF Transponder modulates a wireless signal using 4-state phase shift keying. Send a binary data signal "01101101" from RF Transponder to a signal receiver, verfiy that PSK-4 modulation is used to transmit signal and that signal arrives error free at the signal receiver.||Component|
|V_1.2.1||Verify that microcontroller memory as provided by the manufacturer has 512 kB of non-volatile memory and 256 kB of RAM memory. Inspect manufacturer's data sheets for the required parameters.||Component|
|V_1.2.2||Inspect manufacturer's data sheets for selected microcontroller, verify 8-bit memory and bus structure, and compare clock frequency with that required by RF Transponder||Component|
|V_1.3||Connect RF Comm. Module to microcontroller to receive clock signal. Power up devices with a 5VDC power source and send a RF signal to the RF Comm. Module, verify that signal is processed correctly and sent to the mcu for storage in a memory register.||Sub-system|
|V_1.4||Verify that manufacturer's data sheets show microcontroller compiler/assembler software is compatible with C++, and that a functional debugger is included with the software.||Component|
|V_1.5||Connect Tag to a digital mulitmeter. Operate tag in all modes of operation, observe that operating power consumption is no greater than 50mW, and sleep mode operation is no greater than 5mW.||Sub-system|
|V_1.5.1||Analysis - Calculate battery power consumption based on measured loads from V_1.5, and manufacturer provided amp-hour rating of battery. Test - Perform accelerated load testing on battery by increasing duty cycle to 0.5% per 1 min. period and recording battery discharge power until voltage drops below 4.5 volts.||Component|
|V_1.5.2||Measure battery with a precision micrometer, size must be no greater than0.75 in3.||Component|
|V_1.5.3||Examination - Verify that voltage regulator is rated for operation between 4.6V and 5V. Test - Connect voltage regulator to a new 5V battery, place battery under load and observe that desired 5V down to 4.6V range is achieved.||Component|
|V_1.5.4||Using test setup from V_1.5.3, connect voltage regulator "low-voltage" trouble signal to microcontroller input pin and observe that voltage regulator outputs a trouble signal when battery voltage drops below 4.6V. Trouble signal should be sent to the microcontroller input pin by pulling the signal low, from 5V to 0V. Verify that trouble signal was stored in mcu memory.||Sub-system|
|V_126.96.36.199||Perform test with power supply, microcontroller, and RF Transponder wired together on a breadboard. Energize components and observe that "low- voltage" trouble signal is sent from RF Transponder. After trouble signal is verified, send "fault signal received" signal to RF Transponder and observe that LED on power supply flashes, and microcontroller goes into sleep mode.||System|
|V_1.6||above tag enclosure. Reposition enclosure every four hours to expose all six sides to spray. At end of test, open enclosure and verify that it is moisture free.||Component|
|V_1.7||Place tag on calibrated scale, tag must weigh no more than 5 oz. + 5%||Sub-system|
|V_1.8||Measure tag enclosure with standard dial caliper, dimensions shall not exceed 4" on any long side, and 1" on any short side.||Sub-system|
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.