It is time for you to design a device. You have a great idea. People support you in your idea. You have adequate funding to pursue your plan. It is time to get started.

You plan to create a medical device. Maybe it cleans teeth; maybe it pumps fluids into or out of the body. I don’t know. You haven’t told me yet, but you need to know whether to make a new dedicated device, or turn it into an application for a mobile device. Let’s look at the pros and cons of making dedicated devices and applications.

By making a dedicated device, you have complete control over the product. You decide how it looks, what it does, and when or if it is updated. You can pretty well guarantee that your device will continue to perform in the same way as or better than the day it is purchased. Making a dedicated device also means that you will have to deal with hardware development costs including time, as well as distribution costs that would not have been incurred with just software. Additionally, the burden is on you to ensure that your device passes FDA regulations.

Creating an application is easier up front. You were going to have to develop the software anyway. There is no hardware to be made or worried about or distributed. The lack of hardware is also the downside of this approach. Every time that any device you support gets an OS update, you must be sure that your application not only works, but also that the OS update didn’t open up any security flaws that could affect your device. With medical applications even more than regular ones, if it stops working for even one day, it could cause major problems at hospitals and if it doesn’t work, that may be enough to send users to a “more reliable” device.

Both routes are viable and products have successfully used both in the past. In the case of the applications, updates should come with plenty of warning, and should be testable. Both sides have risks as well. If there are hardware issues or the battery won’t last a whole day, then the manufacturer is the one in charge of fixing it or recalling it.

When developing a product, it’s always a good idea to be on the lookout for laws that might cause problems for your creation. If you started building an apartment complex, you’d like to know in advance that they need to have electricity, right?

When your company decides to build something, it is important to make sure the product has been classified properly. If your new product is intended for use in medical applications, it will need to get the FDA’s approval. The FDA doesn’t regulate medical procedures, just products. Software’s ambiguous nature confuses whether it is a product or not, but since it is code written on a medium, it counts as a physical product.

To paraphrase the FDA’s own words, a medical device is a device intended for use in the diagnosis of disease or other conditions, or used in the cure or treatment of disease in man or other animals, or intended to affect any function of the body.

The FDA may also regulate accessories to medical devices. Dedicated devices used to monitor or control medical equipment are under the FDA’s jurisdiction. There are different levels of regulation depending on the risks associated with the parent product. A controller for an insulin pump would have to meet stricter requirements than a body mass index calculator. Smartphones may house applications and become medical devices, but smartphones have to go through a series of stringent tests already, and the FDA honors many of those tests, but may still do their own.

Applications on smartphones can be placed into three categories: standalone, accessories and components. Standalones do not connect to any other device, accessories are sold to users and connect to standalone devices, and components are sold to manufacturers and are used in the final product. These each have varying requirements for FDA approval. Accessories are regulated to the same degree as the products they connect with, and components are regulated for safety and reliability, as it is the safety and reliability of the end product that is most important.

The Controller Area Network (CAN) had the honor of winning the race to be the OBDII standard and of being the best technology; something that doesn’t always happen with technology. This means that since 2008, the CAN system has been the only OBDII computer system installed in new vehicles.

The CAN system can be visualized like a business inside of a car. The engine controller, stereo, doors, all electronic systems aboard the vehicle are connected. The CAN is like the CEO. It gives the orders and makes sure that the car is running correctly. Throughout the vehicle, there are several LIN-bus systems (Local Interconnect Network) that manage smaller functions. If the driver window needs to be rolled up, the CAN tells the LIN that it needs to be rolled up, and the LIN controls all of the functions needed to roll up the window, saving the CAN from using resources it might need elsewhere. The LIN is like a manager instructing the interns on a project rather than having the CEO use his or her time micromanaging.

The CAN standard is the fastest of all of the previous forms of OBDII systems, which were mentioned in my previous post. It has the ability to manage many functions at once, but new cars have new features, and new features take computing power. Heated seats, de-icing side mirrors and tire pressure monitors take resources too, and even the mighty CAN is beginning to feel the strain.

Just as USB 2.0’s impressive advantage over USB 1.0 is now giving way to USB 3.0, OBDII computers are approaching the point where they will need a faster and more powerful alternative to CAN. The next standard will likely be Ethernet, chosen for its high bandwidth and speed, as well as its proven record of reliability.

The OBDII standard has done worlds for making vehicle diagnostics available to those who need them, but OBDII is still a fairly scary and confusing place for many developers. The most frequent use of a vehicle’s OBDII port is to provide emissions related diagnostics. This has been standardized by the SAE (Society of Automotive Engineers) as the J1979 standard across all makes and models since 1994, and it makes annual inspections quick and cost effective. If all you need is emissions information, it’s a breeze. If you want to interact with the vehicle’s computer, it’s going to be a lot more complicated.

The OBDII standard has historically supported five different interfaces, CAN – ISO 15765, ISO 9141, ISO 14230, J1850 VPW and J1850 PWM. These are ways of talking to the computer, not different things that the computer says. These interfaces are all unique and involve (among other things) different voltages, different message lengths and different connector pins to input and output data. It’s like communicating with a telegraph vs. smoke signals vs. text messages, so it takes a while to understand each method.

In addition to this, the software architecture differs not only across makes, but often across models as well. To make matters worse, no legislative body has required any of these companies to publish any guides to indicate how to do anything on these platforms. This means that any development for OBDII products usually involves a lot of trial and error.

In 2008, the CAN (Controller Area Network) interface won and was made the new standard in OBDII. All vehicles from 2008 onward have used CAN, though they are still allowed to use their own software hierarchy behind it. Even though they all use CAN, Ford still doesn’t work the way VW works etc. This new CAN standard has caused many IC producers to discontinue production of circuitry for the other 4 old standards. It’s going to become more and more difficult to develop for vehicles from before 2008.

When dealing with car troubles, a visit to the OBDII port under your steering wheel can clear up a lot of confusion really quickly. Unfortunately, we can’t just look at the port and tell what’s wrong, so we have to use a tool to read it. These tools come in two varieties: scan tools and OEM tools.

Most people use a scan tool. Scan tools are readily available, and significantly less expensive than OEM tools. A scan tool is a reader with a screen that displays emissions related error codes from the vehicle’s computer. They can tell you whether your check engine light means that your air intake valve is broken or if your knock sensor is getting low electric current. They can read any J1979 codes from any make and model of vehicle, J1979 codes having been standardized with OBDII. Scan tools are available at just about any auto parts store and are usually less than a couple of hundred dollars.

OEM tools, on the other hand, are able to not only read error codes from vehicles; they can interact with the vehicle. These tools only work on the specific brand of vehicle that they were designed for. They are not as widely available due to their prohibitively high cost of tens or even hundreds of thousands of dollars.

Why on Earth would they cost so much? There are several reasons. First and most obviously, they are expensive to make. Secondly, the high price tends to make it only cost effective for the dealerships to own them, concentrating much of the repair service. Third, and most importantly, due to the range of things that this system is capable of, including unlocking doors, rolling down windows and changing the timing of the spark plugs, widespread availability is a bit risky and requires training to prevent vehicle mishaps.

Widespread availability would also be a major liability issue. If people were customizing their cars at that level, they could overload the system and cause a catastrophe, similar to when you run a lot of programs at once on your computer and it runs slowly. Hitting the brakes is not something that can wait for on board computer processing. Mechanics at shops that do have these OEM tools are highly trained, and every product that can control the vehicle through the OBDII port is tested extensively.

The OBD, or On Board Diagnostic computer is what ties all of the electrical and emissions systems together in a car, and it’s come a long way since its invention. You might have noticed the check engine light or low gas light turn on when you look at your car’s dashboard. Before the OBD computers, one of the most common signs that something was wrong was smoke billowing from under the hood or a general loss of cooperation from the vehicle.

The catalyst for the original OBD computers was fuel injection. Volkswagen in 1969 and later Datsun needed a way of fine tuning the fuel injectors with a higher degree of accuracy. Their actions were followed in 1980 by General Motors, who began to install its proprietary Engine Control Module. The ECM controlled the fuel mixture, ignition timing, and idle speed. Very shortly after, the Cadillac line started to come equipped with a diagnostics system that provided error codes and sensor data right on the dashboard.

In 1988, the Society of Automotive Engineers standardized the diagnostic connector port and signals to make OBD maintenance more consistent across brands. Following suit, the California Air Resources Board three years later requires OBD systems on all vehicles made in 1991 and after.

In the mid 1990’s, the OBDII specification came about and became mandatory for all new vehicles after 1996. The OBDII standard includes a much larger list of diagnostic trouble codes. It also standardized output codes allowing scanner tools to read codes from any vehicle with OBDII installed.

Since many companies designed their own software originally, they have been reluctant to standardize. This has resulted in many different formats of software. This makes matters rather difficult for both mechanics and product developers. Mechanics are still able to read many codes, but the ability to make changes requires very expensive specialized equipment.

Product developers must learn to work with every manufacturer’s software in order to assure that new products work with any car that needs it. And just like learning new languages, it takes large amounts of time and effort.

Paragon is wrapping up its work on the ASTech for Automotive Electronic Solutions. The ASTech is a device that solves a problem plaguing small auto repair shops across the country. Each parent company that manufactures cars has a different proprietary software system in their vehicles’ on board computer systems. This can control things like climate control, power windows, windshield wipers, and ignition timing. As vehicles come to rely more and more heavily upon these computer systems, repairs are becoming more difficult for mechanics.

When something goes wrong with the computer, a mechanic must access the system and make changes to the software. The problem is that each brand requires their own specialized hardware and software to interact with the vehicle computer. This equipment is very expensive, and can often cost around $100,000 with annual subscription costs up to 1/3 of that. This overwhelming cost causes most repair shops to specialize in a very limited selection of brands.

The ASTech solves this problem by letting shops remote connect to real equipment housed at strategic locations around the country. Shops schedule an appointment, connect the car to the ASTech, and headquarters connects the car remotely to a real machine of the appropriate brand. This allows the shop to make any changes they need as though they had the expensive equipment in the shop with them. More good news, the ASTech service isn’t nearly as expensive either.

“This is a radical new approach to a well documented problem in the industry. Before, you would have to tow the car to a dealership, let them work on it, then send over two of your employees to go drive it back to your shop. That’s a lot of extra liability that this device completely eliminates.” said Walter McIntyre, Chief Operations Officer of AES. “Now the car doesn’t even have to leave your store.”

Paragon’s involvement in the ASTech project includes providing product development services including the industrial design for the product case, the electrical engineering required to make it work and prototyping, as well as the testing to ensure it was ready for full scale deployment.

To read more about this, read the full article: AES’s ASTech Gives Superpowers to Small Repair Shops

This week, the world of computing lost a hero. Dennis Ritchie, the creator of the C programming language as well as a key developer of the Unix operating system, passed away on October 8, 2011 at the age of 70.

Dennis Ritchie was born in New York in September of 1941, and when the time came, he attended Harvard University, earning degrees in physics and applied mathematics. He spent a significant portion of his career starting in 1967 at Bell Labs, one of the best known research labs of the time.  While there, he and his fellow engineers developed the Unix operating system by 1971 in an effort to develop a more efficient OS for new minicomputers.

Unix proved to be incredibly useful and is still around in many forms and being used in a nearly endless list of applications. The Linux and Mac OSX operating systems are evolved forms of Unix. Embedded Linux is used in an enormous amount of recent products including mobile phones, cable television boxes, networking equipment and medical devices.

His solo creation, the programming language C, has influenced most of the languages we program with today. Some of these include C++, Objective C (used in many Apple products), and Perl, as well the upcoming Go programming language being developed by Google. Other languages that came about because of C include Java, Python, PHP, and C# which was created for Microsoft’s .NET framework.

Many of the electronic devices we surround ourselves with today would not have come about, at least not yet and not in the forms they are today, without the achievements in computer programming from Dennis Ritchie. So wherever you are, say thank you to Dennis Ritchie for propelling the world of technology years into the future.

So, which impacted the economy more: everyone watching the British Royal Wedding, or everyone watching Apple’s “Let’s Talk iPhone” event? Both had their benefits, but both saw significant losses to their respective economies due to employees watching the presentations during work. Let’s look a bit deeper and see what the ups and downs were for both events.

The British Royal Wedding took place on Friday, April 29, 2011, actually a declared national holiday. This was not the only holiday, as the wedding took place the Friday after Easter. British employees were given leave on Good Friday, Easter Monday, the Friday for the wedding, and the following Monday on May 2^nd. Many workers took vacation or called in sick on the Tuesday – Thursday during the wedding week.

This week and a half long holiday cost businesses in the U.K. billions. It did, however, increase tourism, souvenir sales, and local business sales for the shops that had employees at work. It also did England a favor in PR work, reaching over 2 billion TV viewers.

This past Tuesday, the 4^th of October 2011, Apple hosted its “Let’s Talk iPhone” event. This marked the release of the new iPhone that had been hyped since even before its expected release this June. The day wasn’t a national holiday like the wedding, but it may as well have been. This chart shows the impact on the Dow Jones Industrial Average during Apple’s press release. It shows a drop of around 400 points during the presentation (time zones taken into account) with a sharp upturn around 3 pm.

Apple’s stock however was a roller coaster ride all day leading to somewhat of a plummet toward 2 pm EST when the iPhone 4S was announced. Despite this somewhat underwhelming news, people are still excited about it and are likely still going to buy it and Apple’s stock is back on track. This should cause a lot of economic activity focused around Apple and cellular providers.

In summary, the Royal Wedding caused a loss in productivity for most of the country, but increased sales for that time for small businesses in the area, as well as being a great advertisement around the globe for England. The “Let’s Talk iPhone” event caused a smaller loss in productivity and will increase sales for big businesses Apple and the phone companies, as well as anyone who sells the Nano or the iPod Touch. The PR influence for America is not yet known, but will hopefully bring some money to America from sales overseas.

What are your thoughts?

On this long winding road of life we see ups and downs, we have rough patches of unpaved road, and we are offered shortcuts. The best part of the road of life is the journey, but many people tend to choose the shortcuts because of how attractive they appear at the time. I’m not saying that you shouldn’t have fun, but having an “I’m never drinking again!” morning every week can make you miss out on a lot.

Sometimes the shortcuts can be potentially huge like skydiving or doing motorcycle tricks on the highway, and sometimes they can just hug the inside of the turns like any of the myriad of activities that can give us cancer over time.

Medical technology helps to lower the speed limit and add detours. Outside of the metaphor, these things are usually frustrating, but think back and consider whether the detour wasn’t better than driving through the flooded road it led around. And what about the pleasant detours, like stopping at a state park or scenic overlook on the way?

Medical technology can let you experience things you never would have been able to without it. Playing with your pet despite your allergies, running a race again after weight loss treatments or surgeries, watching a grandchild’s school play thanks to a portable oxygen tank; these are all pleasant detours on the road of life thanks to advances and innovations in the medical field.

As you continue your adventure on the road of life, stop and smell the flowers, visit the parks, and look at it with an appreciation for how much better and longer it is thanks to medical technology.