More Software Architecture and Test Engineering

Last time I wrote about some challenges doing software architectures in a primarily hardware group of test engineering. First, we need a definition, so here's one that I had laying around in IEEE 1471:

"Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment and the principles guiding its design and evolution"

The software developed in Test Engineering, at least where I work, isn't so formal as to have a definition. However, we still need guidelines of what an architecture is.

Basically, a software architecture defines the structure of the system, the relationship between the major components, the behaviour of the components. It focuses on the significant elements, extending out to the needs of the UUT (Unit Under Test), and takes into account the needs of the systems users.

Since a lot of testing is sequential, the structure is usually fairly simple. For that simple structure just about anything can be used to document it. However, any threading or other processes or interaction with other processors should be included which can cause some complexity in the architecture.

The relationship between the various resources and how they need to be used to test the UUT needs to be diagramed. Sometimes this is straight forward, sometimes there's some complex interactions. Any communications between componants need to be noted.

Also the significant attributes of how user is involved (user interface). Anything that has user interactions.

That's it in a nutshell. The main thing is to let the team know what is being developed on a higher level. Also, to try to let the managers know you've thought about what you're doing.

Software Architecture and Test Engineering

After a hiatus, I'm back. I broke up with my girl friend which gives me much more time to do the things I enjoy doing and a lot less stress. Robotics, Artificial Intelligence, and my blog. Good nerdy engineering enjoyment.

The Test Engineering group I'm in is made up of mainly hardware people. A lot of them write software, some of them think they can write software, a couple of them really can write software. A software architecture is something required by the process but foreign to them. The bosses, who are mainly hardware types, want to make sure we've thought about the software before we start. Mainly because the hardware guys typically start writing software get to a point where it's a big mess and then patch as well as they can.

In the software past, the software architecture was called the preliminary design. Somewhere along the line someone came up with a paradigm shifting idea to rename it to software architecture. No matter what it's called, it's still just a high level view of the software job at hand.

Almost all of our tests are sequential, simple stimulate and check the UUT. TestStand is our standard test sequencer and we use it very simply, sequential testing with some very minor looping.

It can be a simple functional flow or a simple high level flowchart. We do set of similar tests followed by another set of tests, etc. The architecture is simple, non-complex by real software standards, and straight forward. Almost any thing should be acceptable as an architecture.

Occasionally the architecture will be more complex. Once this happens, then more advanced techniques are needed. More advanced flowcharts or especially UML would be a good candidate. Something to show interactions between different processors and different threads (although, where I work, threads are magic and unknown)

Any of this can prove to the bosses that we have thought about it, the flowchart is what they can understand. The people who are suppose to provide this are agonizing over what to provide and how to do it, taking a lot of time. The good software people are saying to let us know what format you want and we'll give it to you.

This is why we need people who can do software and not just hardware guys who code C. We know how to plan the software.

NI Week is here!

It's finally the NI Week time of year and I am excited! I drove down early this morning. I found I couldn't sleep in spite of my need to get up early and be awake for the 3 hour drive down.

I've come on an Expo pass this year so my learning opportunities will be more limited than previous years but that doesn't dampen my desires to learn, network, and generally be nerdy...one of my favorite pastimes.

I am waiting for the Keynotes to start and thinking...WHO came up with the easy-listening, AC/DC re-mix of T.N.T. along with all the other sad remixes of good music. Basically, this my first disappoint in NI-Week in the last 3 years. I have a feeling I will get over it as the day goes on.

The NI Demonstrations were good but I really enjoyed Jeff K. future state of NI speech. I'm impressed evey year by his talks.

The Expo floor, of course, is very informational, lots of good information and potential uses. The unfortunate thing is, most of the information I gather will either be to new and different to be useful or will fall on deaf ears.

I am going to document what I find out and pass it on.

Again, this year, there is only one CVI demo and they won't let it run because it's to dangerous. It's a desructive test of a CD. Basically the CD crumbles. I guess CVI programmers are braver than LabVIEW programmers. I'm proposing a CVI controlled icamera and potato gun to take out the LabVIEW demo's...I don't think they'll go for it.

Loading TestStudio

I've tried to head into the comparison of TestStand and TestStudio with an open mind, be objective, filter out my biases. However, TestStudio has made this hard to do. Before I do a side-by-side comparison, I plan on learning a little about TestStudio.

We received and I loaded the TestStudio software along with some driver software for the hardware we were going to use. Once I began to explore TestStudio I looked in the help file for a Getting Started section, which I found. It was found to be lacking. It had short sentences like “Create One Library tree” but it had no links to how to accomplish this and no descriptions on how to do this. I searched around and figured this step out eventually, I'm pretty sure. But then the next sentence had the same shortcomings, short, to the point, with no "how" to do anything.

I decided to do it the good old fashion way, trial and error. Choose actions from the menu or right-click and choose actions from the list. I found how to create a step for an annoying “beep”...always fun. However, since TestStudio is browser based, I received a script error. I could not find the options menu item in the TestStudio browser, so I went to my Internet Explorer (IE) and Internet options to turn on scripting. Our IT department, in a fit of control and paranoia, had set no scripting and made it where ordinary users could not change it. While I'm not an ordinary user, I'm not going to do anything to my work computer that would get me in trouble...like give myself admin privs.

Luckily the “beep” node went in and worked in spite of the script error. Accomplishment! I decided to try attaching a node to a DLL. I got the same script error, along with a “Teradyne TestStudio DLL addin has encountered a problem and needs to close. We are sorry for the inconvenience.” message and an error pop up message with only a large red X, no text.

I gave up for the moment and was going to try to talk to the Teradyne guys to get some set up help. So I went back to work, fired up TestStand and immediately got a “Could not start” error. It worked last week, I loaded TestStudio, and now it doesn't work.

I had flashbacks to the Microsoft browser wars of the 90's when IE would cripple other browsers. I'm going to continue to learn, continue to try things, and try to continue to have an open mind.

NI Week...Woohoo

NI Week is almost upon us, it's the time of year to look forward to the new NI products and to network with all the NI people. I'm looking forward to the NI Week. I would be looking forward to all the seminar's and learning opportunities except that this year, some people at the place I work sees no immediate, short term benefit to conferences like this and AutoTestCon. Even in the long term it is hard to show measurable benefit. Since it's mostly secondary benefits, long term learning and networking, that is hard to measure, some groups will be poorly represented.

I am, however, going to to NI Week on an EXPO pass. I am excited about going and I am planning on making the most of my learning opportunities that I will have on my EXPO pass. I want to find out what various vendor's believe is the future of testing. I want to learn about the various products available to help us do our testing, I want to learn all I can...no matter what others think of conferences. I know there are learning opportunities, I know I am going to learn, I know I'm going to learn all I can, and I know it will help me in the future.

Overall, I'm excited about NI Week and all of it's opportunities.

Is Software Engineering relavent to Test Engineering

I've been trying to get a hold of Teradyne's TestStudio in order to compare it to TestStand. It's been about a month and a half since I've been trying to get a copy. Good news...sort of. I'm told my constant requests may have finially paid off. I'm told, Teradyne finally relented and is going to send us a preliminary copy of TestStudio. It may be in the building, it may be in the mail, so I haven't actually seen it. So, hopefully soon, I can do a comparison.

On to other things...

I've been thinking a lot about where Software Engineering fits into Test Engineering. While I understand the fact that it is an integral part of testing, I've noticed a prevailing thought, at least where I work, that software is secondary and trivial piece of the overall testing practice, "You can get anyone off the street to do the software." (qoute from a manager at work)

This thought was brought about when it seemed like I was the only one trying to get a preliminary copy of TestStudio. The tech lead dealing with getting TestStudio seemed unconcerned on getting the software tools while spending endless hours on getting exactly the right hardware. TestStudio was even picked as a software tool with almost zero input from people who deal mainly with software.

Due to the shrinking of many UUTs, a lot of tests are moving to software. Either the UUT is loaded with an Operational Test Program (OTP) or the UUT only has communications port, test software is becoming more and more important. People need more software expertise rather than less software software expertise.

I'm just frustrated knowing that most of the software decisions are being made by the software inept and I may not have a path up the technical ladder because of my leanings toward software.

If you're reading this, thanks for reading my vent.

Peer Review Tool

Last year I wrote a blog about Peer Reviews where I noted all the good peer reviews can do...as long as you do them. I believe that, when done properly, they can catch a lot of problems due to a "second pair of eyes" looking at the code. It also gets others at least sort of familiar with your code. That way, if you get hit by a beer truck, it's easier for someone else to pick up the code.

A peer review tool is an essential part of a groups set of tools. While you can keep track of defects on a piece of paper or in a document file, a peer review tool tends to work much better. On that note, SmartBear software has a peer review tool called CodeReviewer.

CodeReviewer - a simpler CodeCollaborator

SmartBear has a code reviewer sale going on, 5 seats of CodeReviewer for $5, follow the link to read more about it.

Yeah, this is sort of an ad, but lines up with my thoughts and beliefs on code reviews, so I'm putting it out there.

May your defects be trivial and you code be solid!

Comparing TestStudio and TestStand..Not!

Comparing TestStand and TestStudio at this point is...impossible. At the momment, I'm still waiting on the official PO to go to Teradyne so that they will be so kind as to give us the software we're buying. We have sent them 10% of the PO for long lead items but that isn't enough insurance to actually get the software.

It's starting to wear thin, I just want to learn a little about this monstrosity called TestStudio. I am assuming it is a steaming pile of ... code. Until I actually get to see a copy of it, I'm not going to change my opinion.

Once I get to play with TestStudio I really am going to compare it to TestStand. Okay, I do have one bit of pre-knowledge of TestStudio that I can compare to TestStand. Any parameters passed out of TestStudio to a DLL or other code is only allowed to be passed in Character strings. TestStand does it right and passes the value in the form it needs (i.e. integers, doubles, pointers, etc).

Last week the score was TestStand 2, TestStudio -2. The score is now TestStand 3, TestStudio -3 for TestStands ability to pass parameters correctly and Teradynes unwillingness to allow people who are going to use it to actually use it.

Thankful for Family, NI, and Sarcasm

It's the season to be thankful. So in the spirit of the season I want to say what I'm thankful for.

First, of course, I'm want to thank God for all my blessings. Next, I want to thank my family. My Mom and Dad for giving me a good foundation and work ethic and encouraging me to go to collage in spite of their very limited education. I'm thankful for my kids for keeping me grounded through a bunch of tough years and for putting up with me and my warped sense of humor the rest of the time. And I'm even thankful for my hard driving have-to-be-right brother and sweet sister.

I'm Thankful for my really good friends who helped me get past my shyness, helping with my introversion, and helping me get through my tough years. They are fun to hang out with when I don't have a date. In other words, we always hang out.

I'm also thankful to National Instruments for making it easy to do my job. LabWindows CVI is a great tool for Test Engineers and makes it easy to develop code for test sets and for easy to use hardware. I'm also thankful for all the helpful people I've met and worked with there at NI like Joel, Wendy, Santiago, and Conan. I especially thankful for NI Week and the Wednesday night party they throw, maybe happy they do it than actually "thankful". And, yes, I'm even thankful for LabVIEW, it's a good language and most likely a piece of the future of software.

I'm also thankful to both of the Directors I work for, especially JT. They believe in me and know that I'll work hard to do a good job for both of them.

[Start Sarcastic Voice]
I'm also thankful for the boss who said I couldn't follow a process. Now that I've helped deveop our companies processes and reach CMMI level 5, you proved how well you know people. To the same boss who said I would never work in software at our company again. She was right, I'm not in the software group, I'm Test Engineering doing much more and fun software.

I'm thankful to Electrical Engineers. Since most of you guys don't think I can tell the difference between a resistor and an FPGA, you make it very easy to impress you. Especially, to they lead EE guys who couldn't find the problem between the IMU and GPU on LOSAT. You made it easy for "Just a software guy" to find the 25ns glitch that was reseting the IMU with just a schematic and an OScope.

I'm also thankful to the boss who believes that software is just a passing fad. You make everyone else seem so much smarter.

I'm also thankful to the place I work. [insert almost any sarcastic comment from Dilbert and it applies. I'm pretty sure he works where I work]

[End Sarcastic Voice]

The reality of it is I have a lot to be thankful for and I know that I am truly blessed.

Thank you

NI Help

Since I work a lot with different instruments and don't have the luxury of completely learning the ins-and-out of one product, I rely on a companies help functions to get my job done.

Lately I've been integrating some Agilent RF equipment into a test set. I now have a much better appreciation of NI help. I've always felt like NI has some of the best technical help around, examples, and documentation but I've come to appreciate it even more.

I'm trying to use TestStand to control an automated test on an RF Signal Generator, RF Power Meter, and an RF Switch, all from Agilent but having trouble. Agilent really is trying to help but still have a really long way to go to get close to NI help. When I had problems I entered a couple of on-line help requests but received no responses. I had to call the local sales rep to get the e-mail of a tech rep. I have been e-mailing him and he has been helpful in a limited way. I did get the manual web sequence to control the RF Switch, but for automated tests, that doesn't mater.

The RF signal generator was easy because I've used it before and figured out it's quirks. The examples for the RF Power meter had nothing to do with actually reading power, hmmm. When I made calls to the driver functions, they came back with error messages that gave no hint at what was needed. The funcion panel help gave no hint at what the parameters were looking for. I wound up using some low level SCPI commands in combination with the driver functions. I couldn't get it to work with all SCPI or all driver functions.

As for the RF Switch, the examples seem to include calls to driver functions for many different switch types. For my RF switch, the driver functions generate a lot of "Not supported" error messages. But it was very hard to figure out what is supported or what calls I could make. Also, once I loaded the Agilent IO Drivers (which are required for the system to even see their switch) the Pickering switches disappeared from the PXI chassis, at least from a logical standpoint. I still haven't figured that one out.

It's been a week and a half trying to get the RF interconnections to work. I think I'm close but compared to the NI instruments, it's taken way to long.

Using Agilent instruments has given me more of an appreciation for how good NI help, discussion boards, phone help, and e-mail help really are. I especially want to thank Joel Garner, NI Sales Engineer extraordinaire, for his help.

Misunderstood

I've found that the Test Engineering group is misunderstood, at least where I work. Most of the engineering groups have an identity. The Electrical Engineering group builds the hardware, the Mechanical Engineers builds the moving parts, Software Engineers write the software to control the hardware, and the Systems Engineers glue it all together.

It seems what Test Engineering does is a mystery to the other groups. We are called in late in projects because Project Managers don't know why they need us until they realize they need to make more than one widget (or whatever it is they're making). Then they realize their widget (or whatever it is they're building) was designed in a way that makes it incredibly hard to test.

It's too late but that's when they figure out they needed us to begin with.

We're trying to educate the programs on what we can do for them. We can do is:
- We do hardware and we do software.
- We develop systems (Test Systems)
- We can help them design their widget so it can be tested.
- We can make their tests automatic and repeatable.
- We can help with developmental testing
- We can make sure the widget is built correctly
- We can test your system in the field or on the production line

...Bottom line is we can help.

Music and Teams

I was hanging out at the book store, as I tend to do since they have almost all that is needed in life; Coffee, lots of books to read, and free wifi. Some how, I accidentally wander out of the Computer book section, somehow missed the Science and Engineering section and wound up in the music book section. I browsed a book about Zappa for a while but stumbled a book call "Comfortably Numb: the inside story of Pink Floyd". It's a great book!

There were several points that seemed counter intuitive about teams until you realize that Pink Floyd produced many great albums (for the young people, an album is a vinyl disc that music was recorded on and played on a record player...with a needle) including The Dark side of the Moon, one of the best selling albums of all time.

First point, hiring people based on best team fit is over rated. Sometimes the band members were at each others throats. The point was they were all smart, all creative, and they had the drive to get the job done. They didn't let creative differences or personal difference get in the way of there goal.

Second point, some teams fall apart with dissension between team members, some teams refocus their experiences into creativity. Pink Floyd re-focused into writing great music while software teams can refocus into great software.

Third point, Creative people push themselves, and others, hard. Creative people will push themselves to bring their idea's to the forefront and sometimes will push others to get their idea's out there. They seem to push each other, sometimes in not so nice ways, to get people to complete there own ideas.

Fourth point, don't let technology overwhelm the ideas. This one may be a stretch but it has a good point. With Pink Floyd all the technology behind the shows sometimes got in the way of the music. Today, all the e-mail, IM, blogs, distract us from reaching the goal of developing our ideas.

Overall, the parts that I read were very enjoyable. I'm going to have to go back to the bookstore, hangout some more, and read the book. Or, hey, I could actually buy the book! We'll have to see.

LabVIEW...

I have been making a concerted effort to use LabVIEW lately, trying to learn the "Graphical" way of programing. Due to Carpel Tunnel Syndrome I use my left hand to mouse a lot. I've tried the, so called, "Keyboard" shortcuts ("Keyboard" as defined by NI), but since they still involve the mouse, they aren't as helpful as I need them to be.

But continuing to work with the pain, my left hand is just not as dexterous as my right. It's hard to hit the small wire Connections. It's annoying trying to figure out which vi to use for what functions.

Some of the features that would be VERY helpful to get us LabVIEW handicapped people working in LabVIEW is:
- a zoom feature. I could make a vi bigger and actually hit the terminal.
- Or have it where, when I miss hitting a terminal, I can use tab or shift tab to move the connection from the current terminal to the next or previous terminal.
- Have LabVIEW be able to select the end of a wire and then drag it around using the arrow keys instead of the mouse.
- Have the pallet navigable with the arrow and tab keys. Make it where you can select the pallet, then with the arrow and tab keys move about in the pallets to the vi you want. From there, be able to select it and drag and drop with the arrow keys.

Have the LabVIEW developers ever heard about Test Driven Development (TDD) or automated Builds? Here's some more features.
- For automatic builds, have VI's able to be Compiled (or whatever happens to them) from the command line and verified none of them are broken (with the broken arrow for the run button)
- For Test Driven Development, have an automated test frame work. Frame works similar to the NUnit test development suite.

One more suggestion...have a cheaper copy for use by anyone. MS have copies of things like Visual Studio C++ for $100 or so at computer stores.

It's still easier to think in C (LabWindows CVI) than it is in LabView and until I can develop LabVIEW as I can develop C code, I'm sure I'll still be using CVI. But I will always keep trying to learn new stuff.

Now as soon as NI comes up comes up with telepathic programming interface, I'll be there!

OK, Now that we know the Super Intelligent Shades of the Color Green are going to take over the world, lets get on with less important things... like testing.

I've been working on processes and metrics for developing test sets for quite a while now (a couple of years). I love doing technical work so it has been tough doing mainly documentation. I have worked on some test programs part time while working on the processes, so it hasn't been totally tortuous.

I believe there is always a process of one type or another in developing test stations. The problem is some times the process is the POOMA (Pull Out Of My A**) process or maybe the "wing it" process. But then there's the other end of the process universe. This is where the process makes it nearly impossible to do a small project. Then, in the middle, there's the agile process which is suppose to be the processes that allow tasks to be done quickly and with the ability to easily adapt to changes. It's still not a cure all.

Even people who say they have no process, have a process, it's just not as straight forward as most or even seems coherent.

After working on the processes for a while I know that one process does not fit all projects even though that's what we try to do. I was suppose to document the process we go through to build test stations. Each project has been unique in it's own way, with some process steps that aren't in the process and skipping other steps that are in the process. Some projects that try to follow the process finds that outside groups don't follow the process which makes our process fail. There's many reason's process fail.

If the processes aren't working (not that people just don't want to do it), they need to be adjusted , in real-time rather than going through the year long process change process.

The project leads, the one's actually have to make the process happen, have to be the ones to adjust the process as needed. They need the lead way to adjust it as needed. The Process police also need to understand a single written process is not a panacea, it won't cure all. The processes need to be adjusted.

While I've been working on the processes, this is the dilemma I've been dealing with, having processes that don't imped getting things done but satisfies the Process Police.

Green gone wrong

There's a lot of talk about "Green" and Green Engineering. Everything in going Green...Green, Greener, Greenest. Somewhere out there I'm sure there are Engineering positions with the title "Green Engineer".

As we move into the future, there will be more and more Green Engineers. Scientists will go Green to give the Green Engineers more work to do. Of course, the Green Scientist will become smarter and more powerful. Until one day, the inevitable will happen; There will be a Green Mad Scientist. The Green Mad Scientist will then try to take over the world. The Green Mad Scientists will make Green Monsters that will terrorize humanity, but be good for the environment.

These Green Mad Scientists will start working with Green Artificial Intelligence. The Green Artificial Intelligence will develop more adaptable, more specific, and smarter shades of color Green.

These smart shades of the color Green will become smarter and smarter until, one day...there will be super intelligent shades of the color Green wanting to take over the world.

So beware of Green Engineering and the inevitable super intelligent shades of the color Green.

(With apologizes to Douglas Adams and Tthe Hitchhikers Guide to the Galaxy" and to the Super Intelligent shades of the color Blue. You're super intelligent, but not as super intelligent as the super intelligent shades of the color Green.)

Obligatory mention of NI, LabWindows CVI, Test Engineering, and even LabVIEW. I'll write about you all next week.

What I learned at NIWeek

While I could say what I learned about FPGAs or LabVIEW I know that's not the most important lesson I learned. On the last day of NIWeek Andrew Hargadon spoke on "Green Entrepreneurship" ...more or less. He really spoke on Innovation but he told NI he would speak on Green so he could get on the stage at NIWeek.

His talk made me think; It made me think about thinking, about using my brain, about getting things moving in an innovative way, not a new way, but a different, better way.

And that's what I like about National Instruments and NIWeek. Not that there's new products that are Smaller, Better, Faster than the older products. It's about innovation, taking things known, re-combining them, and making something better and getting it out there.

I'm not a LabVIEW fan, I may have said that before, but I am a fan of the innovation of LabVIEW. Dr. James Truchard, Jeff Kodosky, and Bill Nowlin combined the computer, programming, and graphics into LabVIEW, an innovative graphical programming product. It's more than just the Test, the Software, or the Hardware aspects of NI, it's the innovation.

To me, innovation is the whole point of NIWeek, the Innovative thoughts behind the new products. NIWeek inspires me to be innovative, combine old things into new, better things. It get's me thinking along different lines, about more than Test, Software, or Hardware, it's about what can be, about more.

The Experience of NIWeek and the products showcased are great. And it's a good way to get everyone together, to network, and focus on test. But, at least to me, it's much bigger than that. NI Week is like Disney world is to a child. Disney World makes kids imagine what could be. And that's me with NIWeek, I'm imagining what can be.

Now I need to move past the kid in me, and move the imagination to innovation. The next step.

I'm going to NI Week!!

The company I work for has decided to allow me to go to NI-Week. My boss said that anyone who goes will have to give a presentation on "What I learned at NI-Week". Apparently not many wanted to do that, but I'm more than willing to give a presentation to go to NI-Week.

I've also had some e-mail correspondence with a PR person from NI and she said I could check out a USB video camera to record my experience at NI-Week. It will a video for NI but I'm also going to put some of the video here, so I want to get some good footage. I'm looking for any interesting and unique aspects of NI-Week I can find; Or any interesting or unique people I can get on video.

I would also like to meet anyone who reads this and is at NI-Week for the video, too.

I want encourage everyone who is able to go to NI-Week, at least on the free Expo Pass. It's a great experience! Plus Austin is fun, the music on 6th street is great, and UT is there.

Future ot Test Development

Since I am a test developer I think a lot about how to make my own job easier. I believe National Instruments is on the right track in the future of test software with LabVIEW. Graphical is very much the way to go, especially for the Hardware guy forced to write software tests. It still has room for improvements especially with the amount of mousing that it requires. I have mild Carpel Tunnel Syndrome but when I use LabVIEW, it flares up and I have pain in my wrist. LabVIEW also easy to leave out a lot of the discipline really needed for software, things like clean code, readability, and documentation. But LabVIEW is still the way.

In the farther future, I believe that the development of hardware and software will be more coupled and much more automated. NI, again, is doing well on this. With NI-Scope, NI-DMM, and NI-Switch. When you get an NI-DMM card, any DMM card, and use NI-DMM to deal with it. All that really needs to be known is the basics of what DMM measurements need to be made. It's all drop in from there.

The more distance test development future should bring more automated and integrated development. I believe the Test Engineer will specify what signals, tolerances, and communications channels needed to be tested for each of the UUTs that are to be tested. A test development (TD) tool will select the best instruments for the job and layout the Interconnect panel (ICP) (The ICP is where all signals from all the instruments come out to the outside world) The Test Engineer would verify the instruments are right.

The TD tool would use the signal to be tested and instrument it chose to create an Integration Test Adapter (ITA) to self test the station. (ITA take the signal from the Instrument through the ICA and routes it to cables, switch cards, and other instruments). The wire lists for the ITA fabrication would come from the tool. From the ITA and wire lists the software for a test set self test would be generated.

Then the tool will take Save Nowthat ICA output and the UUT signal specs that we started with and would develop the ITA and wire list for each UUT test. Using the UUT wire lists and ITA a UUT self tests software and UUT test software would be generated.

The switch cards needed to route the signals for the Station Selftest and UUT tests would be added to the design.

Below is a simple flow I threw together.

This whole thing is conjecture on my part and very over simplified but, in general, seems doable. Overall, eventually, there will most likely be a lot more automation of layout and test.

Future of Test

One thing that a lot of test engineering companies are doing really well is gathering and analyzing failure data. But in the future the data could be gathered to a central repository and the fault data mined more efficiently, the way some companies data mine for business intelligence. Very likely using some AI techniques to analyze the data. Potentially some type of Neural Net, advanced statistical analysis, and Bayesian mathematics that accepts the failure information and gives the most likely fix. Well, that's what I hope since AI is my hobby. Both test set and Unit Under Tests (UUT) could be analyzed and information about future failures be determined in advanced from current failures.

When a test set or UUT failure occurs the failure information and analysis could be directed to the Test Engineer's pocket PC. He/She would be able to attach to the test set from where ever they are and trouble shoot most problems. Through the remote link some problems would be fixed and some would need to be coordinated with on-site technicians.

As for operating the tests, there could be a central operator planning, scheduling, and controlling all of the tests in a factory. The operator would have the various test screens on his/her screen to interact with the test software. There could be some people on the work floor to make sure everything gets hooked up correctly and the UUT's flow from one manufacture operation to the next.

I do believe wireless and the web will pay a much bigger role in future test. Remote operations will be more common and more advanced failure detection, reporting, and analysis will be the norm.

I also believe that AI will pay a bigger role in test...and not just because it's my hobby.

Future of Test

At work, I've been dealing with innovation, future of test software, and even doing a little bit of real engineering work in my spare time.

With all this I keep wondering, what is the Future of test set? Of test software? How much will change before I retire? When can I retire (different topic)? Also, I was doing an install of some software and had some time to contemplate the future.

I know in the future the Engineers creed of "Smaller, Better, Faster" will be in effect. Also the concept of Cheaper is being pushed really hard. So what will happen in the future.

Smaller is easy. We've seen it happen for years in standards like VME going to VXI and to PXI as well as chassis like the compactRIO. With these different architectures we've also seen faster speeds. So in the next 10 years I'm sure there will be a sub-compactRIO or RIO-micro.

I'm pretty sure distributed systems will be more common. A system where there is a central control and information repository with connections to small "brick" testers that can be put just about anywhere, temperature chambers, remote less access able test area's. There will be wireless connections where possible so that even wires aren't needed. Some type of Ethernet (hardwire or wireless) will connect to the brick and the brick will control and communication with the units under test (UUT). All test results and operator interface will back at the central computer. The central computer will control several different tests at one time.

There will be more embedded test programs in the units under test (UUT), there will be less discrete interfaces. Since UUTs being tested are getting smaller (better faster) too, there will be less area for interfaces. Software expertise will be needed to develop Operational Test Programs (OTPs) to load into units to test them.

With distributed test systems and smaller test sets there will be more "soft" instrument front panels on the display screens and less physical instrument front panels. The soft instrument front panels on the screens would give an image of what the real instrument front panel would look like if it were real. They would control the various instruments manually when it's needed and would minimize when the device isn't being used. Touch screens would be great for this function so that the operator would still "touch" on the interface.

Of course, all this are just some possibilities for the future.