Category Archives: Articles

A Letter to Start-Ups on Technical Development

Lower your Development Costs by as much as 50%

There is a perfection in getting your product into the marketplace as soon as possible so that it can evolve organically rather than waiting for it to achieve perfection.

Dear Start-Up:

Get to a “Minimum Viable Product” as quickly as possible. Whether your “product” is hardware, software, a combination of the two, or some kind of service, not only will you save money, the sooner you get something operating that people can use, the faster they will be able to provide you with useful insight, and the sooner you will have opportunities to refine and, in some cases, redefine you approach. Do not fear mistakes and false starts, as you will get past them and into a position of having happy customers and growing your new customer base.

As its name suggests, a Minimum Viable Product, or “MVP,” has just enough features and functionality to be useful. The bells and whistles can come later, once you have the core product well defined. As easy as this sounds, you may be hard pressed to find a true minimum set of features because you might second guess yourself by thinking that this or that feature, by not being included, could handicap the critical initial release and prevent it from being accepted.

But moving right to a MVP does not mean you start coding today. There is an important planning step that can save you from a tremendous amount of grief and possible failure. This step is the writing of a good technical product specification that will help you decide on the minimum set of features so that your MVP is developed as quickly and as close to your vision as possible.

Listen up: Do not skip this step, even if you think your MVP is not “rocket science.” It may not be, but it is often your young company’s first technical cornerstone, setting forth its basic system architecture and, as such, it needs to provide a strong foundation for what is to come.

Why you Need a Specification

Chances are good that you will need outside developers. If one of your founders is a developer, he’ll probably be too busy with other start-up related issues to be able to dedicate enough of his time to managing all of the development. Besides, if your product is to get out in a timely fashion, it may need more short-term talent … so it’s time to call in some professional developers.

As developers prepare quotations for you, they will ask you for a number of technical items to help them gauge the effort, to neither overshoot nor undershoot your requirements. Examples of such items are technical write-ups, screenshots, mock ups, demonstration videos, sample code, proof-of-concepts, “lab curiosities,” the technical section of your business plan, to name a few typical items which are, by the way, best provided or shown under a non-disclosure agreement. Be mindful of not delivering materials that are focused only in one area, such as the end-user experience, because they may not provide enough detail by themselves to cover the full range of your MVP’s features and functions.

Developers are at their best they receive a high quality technical product development specification against which they can then provide exacting quotations. Besides serving other purposes such as helping you to intelligently determine the MVP’s feature set and establishing your budget, this specification becomes a technical document that liaises between you and your developers. It tells them in no uncertain terms what the product will look like, how it will behave, and what “under the hood” considerations need to be made. It eliminates guesswork on the part of the technicians and programmers. It prevents unpleasant surprises during the course of development when, for example, you and your developer suddenly realize there has been a difference in assumption on some aspect of the product; to resolve this now apparent and unfortunately discrepancy, the development path has to change, the deployment delayed, and the budget revised higher.

Please don’t think that a product specification will take long. We’ve done them in as quickly as a few days and certainly not longer than a few weeks for more complicated projects. Depending on the kind of product or service, a typical specification runs from between 10 and 50 pages. During the writing of the specification, several important issues usually come to light that are best addressed before development is actually begun. These issues are not necessarily technical; they can be related to the business model, customer requirements, and government regulation, among many other factors.

Also, do not think of the time to have a specification prepared as being “lost.” The clarity that the specification will bring to the table will actually allow your product to be developed more quickly overall. Also, some degree of technical research and development work is performed during the preparation of a technical specification, much of which finds its way into the final MVP. Occasionally, there may be multiple technological approaches that need to be evaluated in light of the project’s desired goals. All in all, this engineering-driven specification process with some built-in R&D has the effect of significantly lowering your overall development costs, in our experience by as much as 50%.

Some questions may come to mind…

What will my specification look like? What will it contain? It will be a comprehensive report having, among other things, every feature, every function and every user interface screen of your MVP defined. It has sections of standards, guidance, goals, assumptions, checklists and definitions. it covers all of the MVP’s functional requirements, and some non-functional requirements as well. It deals not only with the software layers but also with what hardware will be used, even if it’s cloud-based, and how it is configured, made secure and has built-in redundancy and backups. It will incorporate your business intelligence, philosophy, personality and value proposition. To the extent of relevance, it will identify vendors, manufacturing processes, and intellectual property considerations. It will contain a proposed development schedule along with an estimated budget.

What does a specification do for me? With proper care, your specification evolves into a “living” guide for the technical side of your business. It becomes an important asset of your company, thereby increasing the value of your company. It can be leveraged to add significant value to your business plan and to your patent filings, and it also becomes a cornerstone for your trade secrets. It can be used to solicit exacting quotations from not only the technical advisory firm who may have helped you develop the specification in the first place but also from a number of other competing firms as well if you so choose.

Should I pay for the specification? Shouldn’t developers do it as part of their quote? Most developers provide free quotes when given a reasonably good specification of what it is they are being asked to do. In lieu of their receiving enough technical material, developers may suggest that you have a technical specification prepared as the very next step. You can do that yourselves or have a qualified engineering team do it for you. Since your MVP’s specification is custom work which has no market other than you, and since it will increase the valuation of your young company, the developers are entitled to just compensation for this preliminary effort. Also, the adage, “you get what you pay for” is very applicable here — you want a solid, engineering document upon which your future can rely. You really do not need a bare bones, short-term “punch list” that will be essentially obsolete a few changes later.

Once you have a properly designed specification for the MVP, your project manager can “shop it around” for maximum cost savings without giving up much in the way of quality. You may choose to break it up into sections so as to help minimize the exposure of your intellectual property and trade secrets. Once one or more developers have been engaged, your project manager will then monitor the project’s progress, providing you with updates and flagging any important issues that need your attention.

As part of the technology strategy consulting that DataPlex provides, our engineers can develop your product specification, act as your project manager, and undertake key portions or possibly all of the technical development to ensure that trade-offs are properly considered and your MVP is developed quickly and to your liking. We can help you develop “customer profiles” and “use cases” that serve to bring closer the real-world to your product’s development. Feel free to contact us to find out how in your particular case we may be best able to help.

Personal Computing Comes Full Circle

Revisiting the Lessons of Timesharing

by Warren Juran

“Those who cannot remember the past are condemned to repeat it.”  George Santayana, might have been talking about how today’s Internet-based computing echoes computer timesharing from the 1960s and 1970s.  How can the lessons learned from that early era of computing help us to design better systems and applications today?  The tale of personal computing’s evolutionary path shows what experienced engineers and developers can bring to the design table.

Once upon a time, computers were so large and expensive that hardly anyone could afford to have one.  Computer users punched their program instructions and data into cards and brought the decks of cards to a computer center.  Operators at the computer center fed the cards into the computer’s input device.  The printed results were available after a considerable wait.  This inconvenient system seemed to take forever to debug software because of the delays after each cycle of correction and re-submission.  There wasn’t much ready-to-use software and the benefits of computing were available to very few.

Computer timesharing let more people enjoy the advantages of “personal computing.”  Hundreds of users could use their own keyboard/printer terminals to share the resources of one central computer.  In the 1960s and 1970s, computer timesharing companies spread around the world, operating large data centers and communications networks to provide dial-up services for their users.  Timesharing companies opened branch offices in large cities and employed armies of salesmen to locate and cultivate new customers.  The new customers could do their own interactive programming, or use extensive libraries of ready-to-use software for their computing needs.

The timesharing companies provided the central computers, communications networks, software libraries, customer support and education, printing services, remote job entry for traditional “batch” computing jobs, client data storage, and a one-stop-shop for word processing, accounting, messaging, engineering analysis and other customer requirements.

Developers of early timesharing systems dealt with issues like utilizing limited bandwidth, providing rapid access to large amounts of data, and insuring that individual users didn’t monopolize computer resources. Tools like “linked lists,” “sparse matrices,” “hashing,” and priority queuing helped improve timesharing systems. Today’s computers and communication networks are vastly more powerful than their early counterparts, but disciplines like Information Theory, Queuing Theory, Distributed Computing and Peer-to-Peer computing can still enhance system performance and reduce costs.

Mobile Computing: Native Apps versus Web Apps

What it Means to Your Organization

by Harry Tarnoff

Our clients often ask about the advantages of mobile applications and the differences between mobile “native apps” and “web apps.” They ask, “How would a mobile app relate to our business, our people, and the products and services we offer? Should our mobile app be a native app or a web app? Should we consider corresponding changes in our business’ IT systems?”

A well-designed mobile app can certainly complement a business’ website and aid in the marketing and sales of the business’s offerings. The selection of a native or web platform will affect an app’s characteristics, what services it can readily provide, and the app’s future evolution. A wrong choice could cripple a start-up or a company launching a new offering. A poorly designed app may never become popular enough to gather a following.

Even more striking is how mobile apps are growing in importance. The percentage of mobile-only users, at 25% today, is estimated to be more than 65% in 2015. This means that, instead of your website, it could soon be your mobile app that tells your customers about you, your company and its offerings. Your mobile apps need the same care, professionalism, and polish as your website and marketing brochures. The quality of your brand must be high for all elements of your public persona.

Fundamental Differences

A “native app” works on only certain devices for which it is targeted. It is written in one of the development languages supported by the target device. A native app runs on the target device and typically stores its data on the device. Native apps can run very fast and can easily interface with any of the device’s hardware and operating system features.

The flexibility of a native app comes at a price, however: Native apps written for one platform, say Apple’s iOS which drives iPhones and iPads, are not compatible with other platforms like Android or BlackBerry OS. Developers spend significant resources to translate, or “port,” their applications to run on each additional device family. Supporting and maintaining similar software for multiple platforms is expensive.

On the other hand, a “web app” is developed using standard web technologies like HTML, CSS and JavaScript. The resulting program, typically accessed through a URL web address, requires only a device with a standards-based browser. An iPhone, iPad, Blackberry, Android phone, or Android tablet can all be suitable clients for the same application.

A web app pulls content from a remote server, so it needs an active WiFi or cellular link. A web app running within a mobile browser generally runs slower than a similar native app, has some restrictions on its user interface, and often cannot take full advantage of special device features.

But the extent of these differences is narrowing. Native and web apps are breaking through their stereotypes. New development platforms let native apps share a common codebase, easing development. Improvements in mobile browsers and new mobile OS features, let web apps mimic their native counterparts and access special device hardware features. Cross-compiling development platforms improve the performance of web technologies.

Introducing AmpUp, a Cloud-Based Enterprise Platform

AmpUp logo

We have developed a web-centric database tool called “AmpUp” used for rapid development of enterprise systems. Born out of necessity for supporting our customers, AmpUp has successfully demonstrated that it reduces implementation efforts and budgets by more than 50%.

Conceptually, the AmpUp tool is a wrapper between an organization’s data and its website. By providing a number of  high-level enterprise system functions for database access, user security and web page generation, developers are now able to concentrate the bulk of their time on their customers’ unique requirements.

AmpUp follows the cloud paradigm of Platform as a Service (PaaS). This is where AmpUp’s functions are available to a public or private cloud and can be shared across several systems. For customers with more sensitive applications, AmpUp is available for installation on their private Intranet as well.

While there is more technical information about AmpUp on the DataPlex website, in this article we would like to focus on these four features:

  • Automatically taps into existing databases
  • Provides instantaneous web forms and reports
  • Enables static and dynamic field dropdown selection
  • Easily adds data record navigation controls

At the Crossroads of Enterprise, Mobile and the Cloud

DataPlex helps you intersect enterprise, mobile and the cloud

Navigate the Intersection of Enterprise, Mobile and the Cloud

As a disruptive phenomenon in the realm of information technology, Cloud Computing is evolving quickly and driving changes both in the personal space and in the corporate world towards a more portable and web-centric infrastructure, particularly in such areas as sales, marketing, customer relations, logistics and fulfillment.

Back in  October 2008, we said “In only a matter of a couple short years, mobile computing with third party applications will become de rigueur, so it would be wise to plan for that eventuality.” It seems we’re on track.

More important than the introduction of the next generation electronic devices such as the latest iPhone and iPad is the prodigious convergence of enterprise IT with mobile computing with cloud-based services. If you missed it, our previous newsletter article “Exploring Cloud Computing” discusses the current state of personal and corporate services being provided over the Internet. It makes cases for when organizations with existing IT structures should explore moving some of their internal and commercial processes over to the cloud.

While one might understand that the cloud is basically a set of remote software services that can be leveraged to reduce the size and cost of in-house IT support, what he or she should also understand is how the growing shift to the cloud is affecting the types of devices and applications we all use.

Exploring Cloud Computing

Volume 4, Number 1

Could You Be Using It Someday?

We have entered an era of Things Cloud: “cloud storage,” “cloud computing,” or, just simply “the cloud,” referring to how IT personnel often represent the Internet in their diagrams. Are there opportunities to save money or get improved processes by moving to the cloud? In our analysis, we find that the answer is a qualified “probably so.”

The Cloud

Most business have already encounter the first embodiment of the cloud, “cloud storage,” also know widely as “online storage,” where data is kept not on your local computer but “somewhere” on the Internet, often accessed through a web portal that serves as a user interface for storage and retrieval. Flikr, Gmail, Facebook, and Remote Backup are examples of large implementations of cloud storage. While cloud storage has been around for a while, the cloud-based concept is in the process of evolving into not just providing data storage but operations on that data as well. We’ve entered the age of “cloud computing.”

The Expansiveness of Mobile Computing

Volume 3, Number 5

What Mobile Computing means to Consumers and the Enterprise

The arrival of the next generation of smartphones such as Apple’s iPhone  and the G1 based on Google’s Android technology heralds a new era in mobile computing. But what does this mean to consumers, and how do enterprises leverage these new devices without sacrificing security?

These are good questions, but let me start out by saying what this article is not. This article is not a review or endorsement of either the iPhone or the G1 phone or any other smartphone as there are simply too many features that matter disproportionately to different types of users.  Besides, there are already plenty of reviews on the specific devices.

Instead, this article abstracts the notion of mobile computing and suggests ways it can and will enhance our lives, whether we are consumers checking our email and stock market investments or as members of a business, collaborating with our peers while away from the office. 

Implementing State-of-the-Art Audience Response Systems

Volume 3, Number 4

“This game is simple,” says Bob Sagat on NBC’s 1 vs. 100 television game show. In this NBC show that airs in prime time on Friday nights in the United States, multiple choice questions are asked, and people are eliminated as they answer incorrectly.

In a “1 vs. 100″ game, a contestant is pitted against one hundred other people, known collective as the “mob,” and collects money for each mob member who gets eliminated. The contestant attempts to increase the pot and take home a sizable amount of money, either the accumulated total of the pot or a million dollars if all members of the mob are eliminated. If the contestant answers incorrectly, the remaining mob members who answered the last question correctly split the pot up to that point.

What may appear “simple” on screen is the result of the successful operation of a multitude of integrated systems in what has to be one of the most technically advanced game shows ever conceived. Behind the scenes is a major IT effort, controlled by a custom version of DataPlex’s state-of-the-art Audience Response System (ARS).

1 vs. 100 set under construction showing four rows of handsets

A view of two of the eight rows
of voting handsets during
construction of the 1 vs. 100
TV game show set (U.S.)

Mob members are placed into the various “pod” locations and often rearranged at the discretion of the director. Each pod has is own graphics display behind the player, microphone and voting handset. There are groups within the mob — lawyers, cheerleaders, janitors, kid geniuses — that are each tracked statistically. Our ARS system supplied through our client Quick Tally Interactive Systems for 1 vs. 100 has a player registration module that is used to set up the demographics and print badges with barcodes for each potential player. Once the mob members are in place in their pods, portable scanners are used to associate all mob members to their locations whose data is then processed by another one of our ARS modules.

Now, how simple is that?

The director likes to know which pods contain returning mob members (mob members who continue to answer questions correctly are carried forward into another game) and how well have they performed in the past. Often, there is a “reigning mob champion,” someone who has answered a significant number of questions correctly over several games. A sophisticated SQL database platform is used for managing the ARS data from multiple games. In a matter of seconds, the ARS data from previous games is processed along with the player location information of the current game, and a report is generated.

There are other IT processes, for example, if a mob wins, a list of the remaining mob members and their information is generated for the show’s accounting department. Also, post production uses demographic-based reports to show interesting factoids on the bottom of the television screen.

Not Your Father’s Audience Response System

A typical Audience Response System, also known as an ARS, collects votes and can generate a limited amount of graphs — bar charts of answer choice selection percentages, pie charts, and some cross reference displays. More recent systems can export directly or indirectly to Microsoft Office™ products, for example to PowerPoint for presentation purposes and Excel for further off-line number crunching. Reasonable stuff, actually.

DataPlex’s experience with audience studies started when in 1980 its early client ASI Market Research wanted to convert an analog dial system to a digital version.  The digital dial version was a huge success and is still used today for allowing audiences to evaluate movies, television shows and commercials before general release.  The audience feedback often had a significant impact on a show’s editing or whether a commerical was shown or not. In the 1990′s this system was expanded for remote voting outside of theaters and for supporting text-based answers by survey respondents.

In 1988, DataPlex started selling its DataPlex DataKeeper, a handheld mobile computing device that featured a world clock, professional time billing, a mileage logger,  and an easy-to-use database manager.  This database manager was used by several customers to conduct surveys where at the end of the survey period, the survey information from each device would be downloaded to a central PC, consolidated, and summary reports produced.  In the mid 1990′s, the DataKeeper received wireless communication capability where survey information and votes could be monitored and analyzed in real-time.  Around that time, several companies developed wireless ARS system packages specifically to handle surveys and votes in a localized region such as a meeting room or a conference hall.

The demands on ARS continue to grow. No longer are more demanding customers content with single location polling and simple summary bar charts. They want to know what’s behind the summary results. They want to compare ARS results across multiple sessions and locations and also correlate the results with those of their other systems.  They want to delve into the data and statistically pull out significant information that will help them improve their business.

On the high end, ARS are expanding above being merely a localized vote gathering tool. Now, it is asked to number-crunch, produce custom reports, feed other systems in real-time, and perform advanced digital and analog I/O (input/output) control.

Metadox ARS performing additional I/O

DataPlex Metadox ARS
Software driving ten individual
player video monitors for
Reader’s Digest’s Word Power
Challenge Championship

In another Metadox application supplied through DataPlex client Quick Tally Interactive Systems, the Reader’s Digest National Word Power Challenge, the application additionally controls ten video monitors with custom statistics for each of ten contestants. Metadox generates special graphics for each display, including showing each player’s name in large text and a red “X” when a player gets a question wrong. Different methods of revealing which players got what question correct or wrong keep the proceedings lively by preventing monotony.

Implementing a State-of-the-Art ARS

With the older ARS, you install the software from a CD that arrives in the mail or downloads from a website, configure it, and you are good to go. On these systems, as features are added, the configuration can get bogged down, and some of the new features may not work with your particular installation.

A state-of-the-art (SOTA) system has the pertinent features tested and qualified by an engineer as part of the process of delivering an exacting product. This step includes testing any hardware add-ons and writing and testing any custom programming code.

Once delivered, a SOTA ARS will require some additional fine-tuning because the installation is brand new. Fortunately, with technical support only a phone call away, most issues can be dealt with quickly.

In extensive applications that require much more customization than is typical, the ARS purveyors might recommend that a feasibility study be performed as a first step as a way to document the scope and detail a reasonable plan for development, lest the project run amok, which of course, is to no one’s advantage.

We are Engineers who Customize for Specific Applications

DataPlex’s niche is providing engineering and consulting services to meet exacting, custom requirements for existing or brand-new systems. We pride ourselves on providing quality products with appropriate levels of training and support. For more information on audience response and voting systems for your own needs, please visit our clients’ sites below.

For more information, please visit:

The Advantages and Pitfalls of Updating Old Electronic Designs

What is an Old Design?

By “old,” we mean systems that were designed more than a generation of technology ago. “Generations of technology” are usually indicated when the class of the components are superseded by a new one. Here are some examples:

  • Microprocessor controlled hardware replacing hard-wired circuits. (There are many advantages for doing so; the resulting design is often less expensive and more flexible.)
  • Digital analog to digital converters (ADCs) and digital to analog converters (DACs) replacing analog circuits. (Typically, a microcontroller site between ADCs and DACs to provide digital processing of the digital version of the signals.)
  • HCT Series CMOS superseding LS Series TTL for driver and interface circuits. (CMOS has faster switching, lower power and can be made smaller.)

A particular hardware circuit is comprised by different sections, and each section may be different numbers of generations old, so a weighted analysis can be used to explore trade-offs of a design upgrade.

For lack of any other measure, an electronic design can be considered old if it is more than ten years old. The electronics industry as a whole advances quickly, and few electronic components are used in the same way ten years later.

One useful question to ponder: If a qualified engineer were to design a circuit today for the same application, how would it be different? The answer helps to point us in the right direction. A new electronics design will utilize parts that are currently available and have a complete yet cost effective feature set. If the design were to be significantly different, then that is a strong argument for not perpetuating the approach of old design, although.

That said, an engineer might still choose to perpetuate an old design based on economic, compatibility and political factors. He may wish to use up existing supplies of old parts, or continue to provide products which meet with customer expectations. Something more technically modernbut significantly different may be perceived by customers as inferior or undesirable. Other technical reasons relate to support and repair and intellectual property issues.

How an Old Design is Updated – The Nine Step Process

Once the decision is made to update an old design, the update process is straightforward. Here is the general process we use at DataPlex:

Step 1
Locate or Develop a Specification of the Current Design

If it was not the first step to break inertia, this should be the easiest step. Old manuals and product datasheets are often useful references.

Step 2
Identify the Key Features of the Current Design

A bit more challenging, identifying key features requires an understanding of the products and, not only how it is used by customers, but also how is it not used. Features that are under-utilized but require significant ongoing support may need to be dropped.

Step 3
Develop a List of New Features, Ordered by Priority and Usefulness

Probably the most difficult step, choosing which features remain and what new features need to be developed has to take into account what are the expectations of the marketplace and weigh them against the up-front engineering expense, the per-unit production cost, and what alternatives provides and what competitors are doing.

Step 4
Research Components and Design Approaches

The design team researches components and explores overall design approaches that seem to optimize between cost, reliability, serviceability and an appropriate feature set. For economic and development schedule reasons, not all features will make the cut (hence the need to order them).

Step 5
Begin Design Approaches

Begin to develop in a top-down approach several different designs to see how then begin to flow. Often one design will leap ahead of the rest as a better or less expensive way. Pick it as the primary design.

Step 6
Review the Designs

Explore the designs with management and (very important) also with key customers to see how well their feature sets fit with their actual needs and requirements.

Step 7
Iterate the Design

At this point, a design team may iterate back to an earlier step should, with management and customer feedback, it become obvious that none of the design alternative sufficiently meet expectations.

Step 8
Start the Primary Design Phase

Once a design seems to be acceptable, the actual primary design phase begins. While it may feel as though the actual design work is a long time in coming, actually most of the difficult decisions have already been made, the complete function set is known, and it is just a matter of implementation. Backup designs can also be begun now or held off for a later time. Also, the design team should work with management to prepare contingency plans should something go wrong.

Step 9
Don’t be Afraid to Go Back

While the main design phase is underway, should any new information indicate that the results may not meet expectations, management should decide which earlier steps should be reviewed to make the necessary adjustments to bring the design back in line. In some occasions, an alternate design replaces the originally preferred design based on the new information. Within reason, it is much better to take some extra time to develop a product that is right for the marketplace rather than push throw with one that is known to be inferior.

When the Design is Complete

When the design is complete, we move on to prototyping and testing.

What Can Go Wrong?

Updating an old electronics design is still an electronics design process and can derail for any number of reasons. For updating a design, a design team must be sure to meet the important targets of feature set, backwards compatibility, production rates, delivery schedule and price points.

It is especially important to get one or more prototypes ready as soon as possible so that the targets can be evaluated by different groups such as management and key customers. These prototypes can also be used for showing to potential customers and demonstrating trade shows while production ramps up. At all times, be vigilant for discrepancies between the prototype and the marketplace’s expectations and acceptance and review Step 9 if necessary.

Should something go wrong — say, production doesn’t ramp up quickly enough to meet the delivery schedule – there is no need to panic. Management should have already developed contingencies such as using more expensive vendors but ones that can fill in the production schedule as necessary.

One area that is particular debilitating is so vast that is deserves its own section…

Intellectual Property Legal Issues

While we do not practice law or offer legal advice, this article would not be complete without a discussion about intellectual property, both developing it and being sure not to step on others.

If it comes to your attention that you are stepping on someone’s intellectual property, you might see what it will take to license it. If the patent assignee’s (owner) is not a direct competitor, you should find a warm reception since you will potentially be providing a new revenue stream.

Or, if you think the updated design improves on the current state-of-the-art for the product class in a novel and unobvious way, you might explore applying for a patent. We won’t tell you that patents are easy — they are not, but should you get one, you will have a government sanctioned monopoly on the invention disclosed in the patent for close to 20 years, hindering competitors and providing a cash flow from licensing.

Note Well: There are ongoing changes to both domestic and international patent law, and you need to be informed about the precise process you will have to follow. For example, as of this writing, a United States invention must have its patent filed before it is first offered for sale lest it jeopardizes its international validity.

In any case, should you feel that you are in such an industry or have a product that requires or steps on intellectual property, gather your design team and consult your patent lawyer.

What to Do if You Have an Old Design

Please consider DataPlex as your one-stop design team. Our products can be found in many different industries and chances our experience staff and proprietary design tools can get you a redesign in quick order. Also, with our being technical and having been successful in written what are now issued patents, we can help you document any new inventiveness so that you can more readily apply for intellectual property.

For more information, please visit:

Maintaining High Reliability for New Electronic Designs Intended for Harsh Environments

Volume 3, Number 2

The Issues of Harsh Environments

Designing a piece of electronic hardware such that it works reliably from the get-go is a challenge, especially if it has to work outdoors or in extreme environments where temperature, humidity, vibration and radiation are the enemies of electronics.

Unfortunately, while a growing number of new electronic designs are destined to be used outdoors, the art of designing for harsh environments is not typically part of an engineering school’s curriculum. As a result, most engineers make the erroneous assumption that designing for a harsh environment is very much like designing for hospitable one but with a greater emphasis on testing and improving the design empirically, addressing the observed failure modes. Although this approach is certainly along the recommended path, it should not be the only extra consideration; otherwise, the deployment could fail.

What is a Harsh Environment?

A quick definition of a harsh environment would be anywhere not “indoors,” although this definition is incomplete. Any condition of extremes relative to the human condition applies, so that includes temperature, humidity, atmosphere (including pressure), radiation and shock, whether indoors or not. While one can easy to see that sitting outside at the south pole with minus 50 degrees winds blowing at 80% humidity easily meets the requirement, it isn’t readily apparent to him that a handheld device that could be dropped five feet also meets the requirement.

A simple test is asking the question, “if this device were a human being (scaled up or down as appropriate) and subjected to the conditions of its environment — the highest and lowest temperatures, the amount of pressure, or amount of shock, would it be expected to survive?” A cellphone operates in a harsh environment, indoors, because it can be dropped, and the amount of force it can hit a tile floor would be terminal to an appropriately scaled human being. (It often is to the cellphone too depending on the height of the drop and the quality of its design.)

The Engineering Approach

Addressing the harsh environment begins before the design phase, in the R&D phase. Knowing that the design includes a harsh environment, an engineer sets the research parameters and, later, the product specifications accordingly. Paramount of concern to him are meeting the minimum and maximum storage and operating condition limits.

To maintain high-reliability for a new design, the engineering approach must:

  • list the extreme storage and operating conditions
  • set the design specifications accordingly
  • select components that meet the specifications and reject others
  • be mindful of circuit board physics, e.g. trace lengths, component mounting methods
  • explore conformal coating and heating and cooling elements, as appropriate
  • ensure that the fabrication drawing is consistent with the harsh environment design
  • select appropriate mounting hardware, cabling and enclosure
  • test the sensor inputs and software over the complete range of operating conditions

“Testing over the complete range of operating conditions” is easy to write, but could be very difficult in actual practice, owing to the exponential increase of possibilities over an increasing number of parameters and ranges. We have found that Monte Carlo Simulation and linear programming are two very useful aids for analyzing the effects of different parameter combinations.

Post-Design & Post-Installation

No design for harsh environment is complete without a plan for follow-up during the implementation or deployment phase. A well-designed circuit may allow additional or alternative components to allow for tweaking the final design after production. For example, in one DataPlex design, a standard delay line circuit slowed down so much in cold temperature that an alternate delay circuit was automatically switched in, and the switch point was controlled by a variable resistance that could be easily changed in the field.

Software is Affected Too

It may not be obvious at all, but software can be affected by harsh environments as well. We are thinking here less of the actual computing hardware that runs the software — that is still covered by the hardware related issues discussed above — and more of the way that the software has been designed and tested in a warm, cozy lab. Software that received sensor data such as values from analog to digital converters (ADCs) may find itself attempting to deal with extreme values that it did not encounter in the lab, and that usually leads to bugs and possible failure.

Taming Harshness

In this article, we explored the nature of harsh environments, what constitutes a quality engineering approach to design a piece of gear for those environments, and the importance of follow-up in order to make adjustments and preempt out-of-spec operation or catastrophic failures.

If you have a requirement for a harsh environment design, we invite you to consider the experience of DataPlex’s staff with difficult environmental conditions and how our refined approach to R&D and engineering can mitigate certain risks for brand-new designs. Please contact us to discuss your project.

For more information, please visit: