Download Final Test Plan

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Document related concepts

Mains electricity wikipedia, lookup

Buck converter wikipedia, lookup

Switched-mode power supply wikipedia, lookup

Opto-isolator wikipedia, lookup

Pulse-width modulation wikipedia, lookup

Variable-frequency drive wikipedia, lookup

Immunity-aware programming wikipedia, lookup

Portable appliance testing wikipedia, lookup

Automatic test equipment wikipedia, lookup

Fault tolerance wikipedia, lookup

Control system wikipedia, lookup

Control theory wikipedia, lookup

Resilient control systems wikipedia, lookup

Distributed control system wikipedia, lookup

Transcript
MSD P10236
TOP SECRET
PRODUCT TEST PLAN
Configurable Control Platform
for Unmanned Vehicles
Note: Many instructions in this test plan assume that the test engineer possesses the knowledge of
how each sub-system connects to each other and how the product is programmed and used in general.
This is done to avoid the numerous and ultimately wasteful reiteration of highly detailed instructions
that will be published in the detailed user guide for this product. Any reader who is not familiar with
the product must consult the detailed user manual and become familiar with the product in order to
assume to be able to perform these tests.
(The detailed manual will still be a work in progress at the time of the evaluation of this test plan, but
when published, it will be available for download on the project EDGE website.
http://edge.rit.edu/content/P10236/public/Home).
Metrics #1 and #2 – Power efficiency / Input Voltage Range
Equipment Required

Lab Power Supply (Rating of 0-5V @ 4.5+ A, 5-17V @ 1+ A) and lead wires

Multi-meter (DC Amperes) and probes

Oscilloscope ( 1MHz+) and probes

Test load (range from 1 ohm – 5 ohms)
Setup
1. Connect PRM input leads (+/- DC Input) to Lab Power Supply
2. Connect test load and multi-meter to PRM output in series configuration.
3. Connect Oscilloscope test probes across PRM Output (parallel with load and meter).
Test
1.
2.
3.
4.
5.
6.
Set Power Supply to 1V and Test Load to 5 ohms
Record Power Supply output current (readout on unit)
Record PRM output current (multi-meter)
Record PRM output voltage (RMS from oscilloscope)
Increase load by 1 ohm, repeat steps 2-5 up to 1 ohm load
Increase power supply voltage by 1V, repeat steps 1-5 up to 17V
Notes
 Power Efficiency = (PSU Voltage * PSU Current) / (PRM voltage * PRM current)
 Calculate efficiency for all data points taken during test
Criteria Metric 1
 PASS = 80% efficiency over operating load and input voltage ranges
 FAIL = less than 80% efficiency over operating load and input voltage ranges
Criteria Metric 2
 PASS = PRM Voltage Output within 5% of nominal voltage output (3.3V, 3.6V, or 5V) for
all input voltages between 4.6V and 5.8V

FAIL = PRM Voltage Output not within 5% of nominal voltage output for all input
voltages between 4.6V and 5.8V
Metric #3 – Guaranteed Operating Time
Equipment Required
 Power Regulation Module
 (2) 3.3 ohm Power Resistors
 (1) 10 ohm Power Resistor
 Ni-MH battery pack
 Digital Ni-MH charger with charge energy reading
Test
1.
2.
3.
4.
5.
6.
7.
Charge Ni-MH battery pack.
Connect 3.3 ohm resistors to 3.3V and 3.6V output rails
Connect 10 ohm resistor to 5.0V output rail
Connect battery pack to PRM (will run at 9.4W)
Run PRM at full power (9.4W) for 30 minutes
Disconnect and recharge battery pack
Note the recharge energy in mA-hours.
Notes
 The PRM maximum output power exceeds the maximum possible power consumption
of the entire system by a large margin. Therefore, although this test does not involve
running the actual system, it WILL result in the extreme worst case operating time.
Criteria Metric 3
 PASS = After 30 minutes, no more than 2/3 battery capacity is used
 FAIL = After 30 minutes, more than 2/3 battery capacity is used
Metric #4 – Provides Mounting Points to Vehicle Chassis
[Test by Design]
Criteria Metric 4
 PASS = Product provides mounting holes to accept mounting hardware. Holes are predrilled, or a surface is designated for drilling for mounts. Mount is appropriate for
attachment to flat surface.

FAIL = No mounting points are supplied, and there are no proper places to drill and
attach the product to a flat surface.
Metric #5 – Total System Weight
Equipment Required

Scale (Range 0 – 3+ lbs)
Test
1. Weigh total system (Platform Assembly + IOB)
Criteria Metric 5
 PASS = Product less than 3 lbs in weight
 FAIL = Product more than 3 lbs in weight
Metric #6 – Operates over expected operating temperature
Equipment Required
 MonoKote® Heat Gun (for model aircraft)
 Freezer
 Box or other enclosure to fit whole system
 Computer with Terminal (for serial communication)
 USB Cable, Power cable for IOC
 Temperature sensor connected to IOC through IOB
Setup
 Power ON Control Platform
 Connect to IOC via Terminal through USB cable
 Load Platform with Simulink Model
Test
1.
2.
3.
4.
5.
Put system into enclosure
Initiate Simulink Model Execution
Add heat from heat gun into enclosure until temperature reads 38C
Monitor system I/O through Terminal, note any crashes or errors
Put system into freezer, note any crashes or errors
Notes
 Because it is difficult to find a freezer to -20C, test may not be feasible to that low of a
temperature. Verify as low as possible with test, supplement with theory.
 System will report any device communication errors, and in general, data can be
monitored for ballpark expected range. It is impractical to take this too far.
Criteria Metric 6
 PASS = All sub-systems operate without throwing errors for [ __ ]C to 38C
 FAIL = System crashes while within desired temperature range of -20C to 38C
Metric #7 – Power and Programming ports are externally accessible
Test [Inspection]
 Verify that programming port and power connectors are accessible without removing
the product from casing or removing the casing from the vehicle
Criteria Metric 7
 PASS = System power and programming ports can be accessed without removing any
part of the system from vehicle

FAIL = System must be removed in some way to access ports
Metric #8 – Compatible Simulink Blocks
Equipment Required
 PC running MATLAB Simulink™ and Terminal, with USB cable to IOC
Setup
1.
2.
3.
4.
Install CCP_GPP tool-chain
Prepare Simulink Model containing all blocks to test
Configure IOC and Sensors to make data available to CCP (use UI)
Connect
Test
1.
2.
3.
4.
Run C-code generator in Simulink Real-Time Workshop using ccp_gpp.tlc tool-chain
Link compiled model I/O blocks to parameters using the UI
Compile / Load the model and configuration to the Control Platform
Run code on Platform – monitor model parameters through IOC USB port
Criteria Metric 8
 PASS = Model successfully builds, compiles, and runs on CCP
 FAIL = model can not be successfully built, compiled, and executed
Metrics #9 and #10 – I/O Throughput / Control Processing Bandwidth
Test
1.
2.
3.
4.
Connect UAV IOB, CCP, and IOC
Load UAV IOB peripheral drivers
Run 1000Hz control system on CCP ( i.e. MAV II model)
Verify no errors thrown to Terminal monitor
Notes
 The CCP and all sensor test driver will throw overflow errors if the requested control
cycle execution or data transfer rate exceeds their limits. These errors are specifically for
the testing of these two metrics. If no overflow errors are seen, control model speed is
slow enough for proper execution, and this spec is met.
Criteria Metric 9
 PASS = The IOC and I/O cores execute control model without throwing overflow errors
 FAIL = The IOC or the I/O cores overflow when data request rate is 1000 Hz
Criteria Metric 10
 PASS = The CCP does not throw any overflow errors during code execution at 1000 Hz
 FAIL = The CCP throw overflow errors during code execution at 1000 Hz
Metric #11 – Non-volatile storage for control code
Equipment Required
 CCP Module with programming cable
Test
1.
2.
Upload compiled Simulink® control code (50kB+ in size) to CCP FLASH storage
Reboot CCP without programming cable connected
Criteria Metric 11
 PASS = CCP boots and runs control code without re-programming
 FAIL = CCP is unable to boot and runs control code without re-programming
Metric #12 – Architecture bit length/accuracy
Equipment Required
 Computer with Terminal
 Power Supply (capable of 3.3V output)
 IOC and IOB Modules
Setup
1. Connect power supply to one of the IOB analog headers (+ / - inputs)
2. Set power supply output to 3.3V
Test [demonstration]
1. Send Terminal request for ADC value
2. Show that maximum value is 0xFFFF (16-bits, all ‘1’)
Criteria Metric 12 (a)
 PASS = ADC output is 16-bits
 FAIL = ADC output is less than 16 bits
Metric #13 – System can use external waypoints and data in control code
Equipment Required
 Computer with Terminal
 IOC, IOB, and CCP with USB programming cable
 Hobby servo
Setup
1. Load a simple Simulink® Model with one input that is looped back to drive one of the
PWM outputs proportional to the input value
2. Connect the hobby servo to the PWM output on the IOB
Test [demonstration]
1. Using Terminal, write a value to the shared memory for the model’s input
2. Repeat [1] if desired, showing the servo move after each command
Notes
 The operation of the Terminal interface is identical to that of the UART interface of the
telemetry unit. Demonstrating that values entered from the terminal can be used to in
the control code demonstrates that data input from an external source can be used in
the control model by this method. Since the CCP can use the input data as any type of
input (a waypoint, a sensor value, a command), the successful demonstration of this test
is adequate to prove the ability of the user to use ANY external data in the control code.
Criteria Metric 13
 PASS = Manually-entered data successfully affects servo output

FAIL = External data cannot be used by control code processor
Metric #14 – I/O peripheral types, numbers, and pin-outs are configurable
Test [Inspection]
Notes
 At the moment, the software back end for this feature is still in development. However,
anyone with knowledge of micro-controller GPIO behavior can, by inspection of the test
code currently in place, verify that peripheral types, numbers, and pin-outs can be set.
This demonstration will be fully developed at a later time.
Criteria Metric 14
 PASS = Types and numbers of I/O types readily are configurable in the user interface
 FAIL = The user cannot change the set of peripherals attached to the system
Metric #15 – All source data is freely available and documented
Test [Inspection]
 Download a snapshot of the repository
 Check that all code is compliable and cleanly organized
 Check that code meets documentation standard
 Check for complete schematics and layouts of every board
 Demonstrate configuration and programming according to documented instructions,
show that no undesired software is required to use the final product
Criteria Metric 15 (a)
 PASS = The software and data used to construct the final product is openly available to
the public. The re-generation of the product does not require any software that requires
a license to use, except the specific case of MATLAB Simulink RTW. Code format and
commenting is clean and clear

FAIL = The use or reproduction of the system requires the licensing of proprietary
technology from one or more third-parties. Code is messy, uncommented.
Criteria Metric 15 (b)
 PASS = The procedure can be reliably reproduced using the instructions in the
documentation

FAIL = The product cannot be used using only the instructions provided
Metric #16 – I/O peripherals connect externally
Criteria Metric 15 [by Inspection]
 PASS = Control Platform can be removed from vehicle without the need to also remove
the attached vehicle sensors or other peripherals

FAIL = Removal of the Control Platform requires the otherwise unnecessary removal of
one or more of the other vehicle peripherals
Metric #17 – Physical Size
[Test by Inspection]
 Insert control system into Airframe C
Criteria Metric 12
 PASS = Total system package fits within the allocated space on Airframe C
 FAIL = Total system does not fit in allocated space on Airframe C
Metric #18 – Provide interface to telemetry
Equipment Required
 Computer with Terminal
 IOC
Setup
1. Connect Computer to IOC via USB cable
Test [demonstration]
1. Using Terminal, show that interface with IOC is possible (issue commands, read values)
Notes
 The Terminal interface is identical to the IOC as the telemetry group interface (UART). In
other words, the IOC’s ability to communicate with the computer Terminal is a
guarantee that the telemetry interface will work when that system finally exists, and is
ready for testing
Criteria Metric 19
 PASS = Final design is demonstrated to be able to communicate via UART, and
collaboration has taken place to guarantee compatibility and functionality

FAIL = No provisions are evident to suggest that telemetry project hardware interface
is compatible with final product, or that UART is supported in general
Metric #19 – Non-volatile removable storage for logged data
[Test by Demonstration]
1. Connect IOC and IOB
2. Attach signal generator to IOB analog input
3. Load and execute SD Data-logger driver and test program into IOC
4. After test completion, remove SD card and plug into computer
5. Verify data is written to SD card, and plot data in Microsoft Excel to verify accurate
reproduction of the analog input signal
Criteria Metric 19

PASS = Data is successfully logged non-volatile, removable storage. More than 8.4MB of
space is available.

FAIL = Removable storage is not supported, or is not capable of storing at least 8.4MB
Metric #20 – Voltage ranges of analog sensor inputs
Test [demonstration]
1. Connect UAV IOB to CCP
2. User Terminal test program to monitor each analog sensor input
3. Verify that no clipping occurs in targeted range (1.8-4.5V)
Notes
 The voltage range of any analog sensor can be conditioned to meet the input
requirements of an ADC. Signal conditioning on that level is not necessarily part of a
reasonable scope for this project, and is, therefore, the responsibility of the end user.
However, demonstrating that the analog sensors for the UAV CAN be properly input to
the system is the true goal behind this metric, and can therefore be verified.
Criteria Metric 20
 PASS = UAV analog sensors are correctly read without clipping through full expected
range of operation

FAIL = UAV analog sensor inputs cause clipping of input data that cannot be fixed or by
an adjustment on the I/O Breakout Board
Metric #21 – Number of analog channels
Test [demonstration]
1. Connect signal generator to one ADC input channel
2. Use Terminal to verify that data can be read from that channel
3. Repeat [1] and [2] for each channel
Criteria Metric 21
 PASS = Design supports the ability to connect and read at least 3 analog inputs
 FAIL = Design supports less than 3 analog inputs
Metrics #22 and #23 – Protocols Supported / Concurrent Digital Peripherals
Test [demonstration]
1. Connect one of each type of digital peripheral (SPI, UART, I2C). In this case, the UAV IOB
with connected SPI IMU and NMEA UART is ample. I2C is optional, and can be tested
separately.
2. Load test driver for each device onto IOC
3. Using Terminal, show that data is acquired from each digital sensor, and that both can
be connected and used without reconfiguration
Criteria Metric 22
 PASS = Device is capable of GPS NMEA (UART) and SPI (IMU) protocols
 FAIL = Devices does not support both UART and SPI
Criteria Metric 23
 PASS = At least two digital devices (1x SPI + 1x UART) may be connected and used by
the system at the same time on the same mission

FAIL = Does not support digital peripherals, or only one may be used per mission
Metric #24 – Tool set necessary to disconnect vehicle peripherals
Test [demonstration]
 With the IOB and IOC connected as when installed in the vehicle, disconnect the IOB and
remove the IOC.
Criteria Metric 24
 PASS = The IOB can be detached from the control platform using a reasonably limited
set of standard in-field tools (i.e., screwdriver, wrench, hand)

FAIL = Detaching vehicle sensors from control platform requires an extended toolset,
and is unreasonable to service in field
Metric #25 – Control parameters, sensor data and system status is
externally accessible
Test [demonstration]
1. Connect CCP, IOC, IOB
2. Configure Simulink control program to output intermediate system values for debug
3. Connect system to USB interface and program control system
4. Read control model intermediate debug values from Terminal during code execution
5. Read sensor data and system status message from Terminal
Criteria Metric 25


PASS = Debug values and sensor values are available from Terminal
FAIL = Debug values or sensor values are inaccessible from Terminal
Metric #26 – Manual Override
Test [demonstration]
1.
2.
3.
4.
5.
6.
7.
Connect control platform to UAV IOB
Connect R/C Receiver to UAV IOB
Load CCP with test control code to fluctuate servo outputs
Connect at least one hobby servo to IOB PWM output
With system enabled and override disabled, show that CCP has control over servo
Switch the manual override ON, show that servos are now under manual control
Switch the manual override OFF, show that CCP regains control over servos
Criteria Metric 26
 PASS = Upon enabling override, the control servos stop responding to control code. R/C
transmitter has complete control over servo motion.

FAIL = Upon enabling override, the control servos fail to follow R/C transmitter inputs
without interference or sporadic behavior.