Abstract
A system was developed in a laboratory on a desktop computer to evaluate armor health. The system uses sensors embedded in the armor which causes the armor to vibrate. There are subtle changes in the vibration pattern if the armor has been damaged. The system uses these changes to diagnose armor health. The goal of the team was to take this application and transfer it to the field where it would be embedded in a portable system that could be readily used by soldiers.
The original application was developed on a desktop computer that had a powerful processor, 4 GB of memory and a standard operating system. The challenge was to take this application that had essentially unlimited resources (disk, memory and processor) and modify it to run on a microcontroller which has rather limited resources including no disk, no operating system, very little memory, and a much slower processor. There is no explicit general method that will work for every application, however it is hoped that the steps described below will provide a general framework for the process and some insight as to how to approach the task.
1. If the application has several main programs, start the conversion efforts with the simplest main program first.
2. Start with the source code for the application and reduce all array sizes to the minimum necessary to run the application.
3. Replace double precision data declarations with single precision data declarations wherever possible. This requires careful checking of the application to make sure that the required accuracy of the computations is maintained even with the reduced precision.
4. Remove all standard file input/output references from the source code while converting the application for the micro. Replace these references with appropriate workarounds.
Form Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number.
REPORT DATE
2. REPORT TYPE A system was developed in a laboratory on a desktop computer to evaluate armor health. The system uses sensors embedded in the armor which causes the armor to vibrate. There are subtle changes in the vibration pattern if the armor has been damaged. The system uses these changes to diagnose armor health. The goal of the team was to take this application and transfer it to the field where it would be embedded in a portable system that could be readily used by soldiers. 
Technical Report
#23658


SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)
U.S. Army TARDEC, Ground System Survivability, 6501 East Eleven Mile Rd, Warren, Mi, 48397-5000
SPONSOR/MONITOR'S ACRONYM(S)

TARDEC

SPONSOR/MONITOR'S REPORT NUMBER(S)

DISTRIBUTION/AVAILABILITY STATEMENT

Approved for public release; distribution unlimited

SUPPLEMENTARY NOTES

ABSTRACT
A system was developed in a laboratory on a desktop computer to evaluate armor health. The system uses sensors embedded in the armor which causes the armor to vibrate. There are subtle changes in the vibration pattern if the armor has been damaged. The system uses these changes to diagnose armor health. The goal of the team was to take this application and transfer it to the field where it would be embedded in a portable system that could be readily used by soldiers.
SUBJECT TERMS

microprocessor, desktop computer, algoritm modification

SECURITY CLASSIFICATION OF:
17. LIMITATION OF ABSTRACT 5. Modify the algorithms used if necessary to reduce the memory requirements so that the application will run on the micro.
The steps above will be illustrated by applying them to a practical example.
Description of the Example Application
The example we use measures armor health. Sensors are placed in armor and these sensors are subject to ultrasonic vibrations from 1 to 200 kHz by 1 kHz increments. The responses of the armor plate to these vibrations are collected, and the average and standard deviations of the strength of these vibrations are stored in a database. When the responses to the healthy armor plate are collected over time, random errors tend to cancel each other, and the means and standard deviations of the responses can be used to create a database which is called the "fingerprint database". This database represents the "ideal" behavior of the healthy armor plate and it can be used at some future time to check the armor. A data file is collected and compared to the database to determine armor health. If the data file differs substantially from the fingerprint database, it indicates that the armor has been damaged. The system was developed so that it has two main programs, the database builder and the compare function which is used to compare a new data file to the database. The main programs are quite simple, and most of the computation is done in a software library which is common to both main programs. The compare function is much simpler than the database builder, so we shall consider it first.
The Simplest Main Program: The Compare System
The compare system uses limited memory since it does a calculation using an input of 200 data points and a database of 400 data values (200 averages and 200 standard deviations). The program is written in the C programming language. The standard method for developing an application for the micro is to first develop it on a pc. The application is then downloaded to the micro for testing. The program on the pc for developing micro applications is called a cross compiler. After successful program execution on the pc, the program is downloaded to the micro and run there to test for any problems. The first step was to develop a C program on the pc that implemented the compare system without using any data i/o that would meet the micro's data memory and program memory limitations. The pc contains only one kind of memory and it can be used for either programs or data, while the micro contains two kinds of memory, SRAM for programs and flash that can be used for data.
Reduce Array Sizes
Comparison The first step was to reduce array sizes where they are much larger than actually necessary. For example if an array has dimension 1000 to accommodate 1000 files, but more than 100 files are hardly ever used, the array size can be reduced from 1000 to 100 thereby reducing the memory requirements by 90%.
Due to the fact that current desktop computers have essentially unlimited memory (a minimum of at least 4GB on most computers) programmers have become very generous with allocating array sizes. The result is that a program that uses an array of size 100 may have an array dimensioned as 1000. 
A Case where Double Precision is Necessary
A rather simple case where double precision is critical is in the calculation of the standard deviation of a set of numbers. There are 2 common algorithms that can be used to compute the standard deviation. The first algorithm has the following steps:
First algorithm
1. Compute the average of the data and store it in a variable ave.
2. Then subtract the average value from all the data elements, and square the values, and take the square root of the sum.
2 ) where X i are the data points. This formula for calculating the standard deviation doesn't usually require the use of double precision. It does however require processing the data elements twice, once to compute the average and once for computing the standard deviation. It also is very wasteful in storage since an array of size n or more is needed for storing the data points. This method doesn't require much storage since it only uses two accumulators to sum up the data values and the square of the values, but it more susceptible to numerical errors.
Consider the following situation where the standard deviation of 500 randomly selected data points where chosen between the interval of 500 and 501. The only difference in storage was that the two accumulators for the variables in steps 2 and 4 above were in double precision instead of single precision for a difference of 8 bytes of additional storage required for the double precision data type.
Developing the code for the micro on the desktop computer
Before compiling the code with the cross compiler for the micro, it is useful to do as much of the necessary modifications as possible on the pc. The reason for this is that it is much simpler and faster to modify and test an application on the pc than the micro.
There are several stages in this effort.
Eliminating Unnecessary Routines
The compare application consists of a main program and it calls a library with 64 subroutines. The library contains many subroutines that were used by various main programs, but most of them are not needed by the compare program. For example the library had several routines to read several types of data files including ASCII and binary files. However since the micro doesn't have a file system, no actual read routines were needed. By eliminating all unnecessary routines and combining some routines, the number of required subroutines was reduced to 6. To preserve the functionality of the application it was necessary to replace a read routine with something that could get the data to the application.
The original read code was a typical routine that had as input a file name and it returned a vector of data values as output, and the number of data values. It was replaced with the following C code which emulates a read routine: The revised program was compiled and executed on the pc and it gave the same results as the original program. The next step was to cross compile the program for the micro. The following image from the laboratory computer shows that micro computer version was successfully generated. The code was then uploaded to the micro where it successfully executed and gave the same numerical result as on the pc. As is shown in Figure 5 , only a small amount of Flash and SRAM resources were used for this application. The next question is will the database builder application fit and run on the micro?
The More Complicated Main Program: The Database Builder
This program is called the fingerprint program because the database is sort of like a "fingerprint" of the armor panel that it represents. One of the principles of statistical theory is that by repeating an experiment over time, random errors will tend to cancel out each other. This requires the collection of data over time and under varying ambient conditions. Collecting and storing day over time requires the existence of a file system and a clock, but not an operating system. Fortunately a file system is commercially available for the micro that only requires 1300 bytes of storage. The data can be stored on a compact flash or sd card either of which can be integrated into the system hardware. To build a representative fingerprint database can require the collection of several hundred data files. The compact flash card has more than enough space to store these data files since each data file contains only 804 bytes of data. One thousand data files would only require 0.8 megabytes of data, and a common compact flash card can hold 32 GB of data. However the micro doesn't have sufficient storage to hold this data in core for processing. The solution to this problem is to use random sampling and choose a small subset of the total number of data files for processing. The following table compares the results of using the original program and the one that was rewritten for the micro. The table above compares the database values from the two versions of the program, but it doesn't really give much of an idea as to the ability of the micro version to produce results that are comparable to the original version. A better way to compare the two versions is to see graphically depict the metric values using both of the two databases. Figure 7 shows this comparison. In general the values are similar, although some of the values using the micro version are twice as large as those for the original version. The really critical test however, is can the micro version detect changes in armor health as well as the original version? Figure 8 shows that both versions are able to detect changes with similar precision. In fact the scores from the micro version are slightly higher than those for the original version. The average score for the original version is slightly greater than 1900, while the score for the micro version is about 2600. 

{'paper_id': '107906295', 'title': 'Lessons Learned in Adapting a Software System to a Micro Computer', 's2_url': 'https://api.semanticscholar.org/CorpusID:107906295', 'source': 'S2ORC'}