Reinventing manufacturing tests for automotive electronics

 Ram Mohan Ramakrishnan

Ram Mohan Ramakrishnan

Automotive electronics has been making steady gains in percentage cost of the total vehicle cost world-wide. Consequently, it has been facing some of the same challenges that were faced earlier (and mostly solved by automated tests) in other areas of automobile mass-manufacturing – fabrication, mechanical assembly, electrical components and hydraulic systems.

A typical example is the Electronic Control Unit (ECU) that has become the heart (or brain!) of the modern automobile. An ECU receives inputs from various sensors and sends outputs to multiple actuators, in addition to communicating with other ECUs of related subsystems in the vehicle. Some ECUs implement performance critical functions such as fuel injection, ignition timing etc., whereas others control safety critical systems such as Anti-skid Braking (ABS), Electronic Stability Control (ESC) etc. Therefore an automated manufacturing test station for the ECU is significantly complex in design, involving several pieces of instrumentation, simulation of sensors and multiple automotive communication protocols.

Let’s see if some real-world figures could lend a quantitative perspective to this mass-manufacturing challenge. For instance let’s take the case of a mid-size automotive OEM that sells over a 100,000 vehicles annually, with production in 2 plants of identical capacity. That would mean at least (taking Engine Control) an equal number of ECUs supplied annually by their Tier-1 ECU Manufacturer who needs to manufacture around 8 ECUs in an hour, assuming full 3-shift operations. Assuming 4 parallel assembly-lines, it gives less than 30 minutes to manufacture an ECU! The time available practically for testing ECUs at the End-of-Line (EoL) is even shorter. Assuming 2 parallel test stations, the operator typically would have less than a minute to test an ECU – to load it on the test station, execute the automated tests, to know if it passed or failed, print a bar code and affix it to the passed piece (or dump the failed piece into the reject bin) and unload the ECU, and ready to load the next one! Added is the complexity of different versions of the same ECU that are simultaneously in production. Since batches having different versions of ECU come to the same test station, the operator would need to reconfigure the station for a different set of tests each time. The reconfiguration must be completed typically within 4 to 5 minutes before loading the next ECU type.

Now let’s review how this challenge applies (or doesn’t apply!) to different segments in the automotive industry. It’s a no-brainer that any Tier-1 Manufacturer (or OEM) in the business would have all of this covered in their factory floors already, if not they would hardly be selling! However it is no longer the steady-state in the case of a newly introduced ECU design, be it part of a new brand of vehicle the OEMs plan to introduce to the market, or be it related to an additional feature, like adaptive cruise control, that’s being introduced for a new model variant. Does the Tier-1 Manufacturer have the required engineering bandwidth to design the test station themselves? In the case of technology transfer for ECU design from a global principal, does the Tier-1 Manufacturer have in-house expertise in the early stages to develop a test station on time before pilot production starts? In the case of in-house development of the ECU, does the Tier-1 Manufacturer really have the resources, bandwidth and simply the time to get the test station ready before the ECU design passes all type tests and hits production?

Alternatively, do existing test station vendors for other components, like starter motors, tiltable mirror assemblies or instrument clusters, have the necessary expertise to design such a complex test station? What about ECUs for Electric Vehicles (and hybrids) that are predicted to transform the entire motoring landscape forever! Not to forget the two-wheeler (and three-wheeler) segments, which under the rapidly closing time window of emission control regulations (Bharat Stage-VI in India although behind Euro-VI by a few years, has a 2020 deadline currently!) will be forced to switch to ECU based fuel-injection etc. in a few years’ time in order to legally sell in the market.

Here’s where a little foresight into accelerating the design of manufacturing test solutions could benefit the relevant stakeholders. At Deep Thought Systems, We have designed and developed a reliable, modular and generic platform called TestMate for building manufacturing test stations specifically for ECUs. We have successfully customized Testmate to supply EoL test stations for ECUs to Indian Tier-1 Manufacturers and OEMs in a very short turnaround.

The Human Machine Interface (HMI) of the Testmate, the main part that the operator sees and operates on a continuous basis, is a very generic requirement that consists of rugged enclosure, controls and indications for long years of reliable performance in an assembly floor. They say, and we’ve witnessed it ourselves, that routine use of test stations by the creed of factory operators indeed constitutes a really hash environment! The mounting, orientation, peripherals for viewing and printing, display properties etc. are all ergonomically designed, optimally for continuous usage by an operator over an 8-hour shift (or longer!). We have successfully installed the test station in factory floors where they are being used continuously for years, with zero support calls.

We work with the customer on the ECU connector type, to design a custom cable harness and test fixture that includes the mating connector, with locking arrangement. The fixture design ensures proper contact between the pins of the ECU connector and the mating connector over months of continuous loading and unloading. We equip the customer with spare cable harness to handle the unlikely event of damage due to exceedingly rough/careless usage by operators, which can be easily replaced onsite without having to depend on a service engineer.

Built on the same principles as our other automotive offerings for vehicle diagnostics, testing and simulation, Testmate is capable of communicating with various ECU designs over multiple automotive communication protocols like CAN, K-Line and LIN and messaging standards like J1979, J1939, UDS, KWP2000 etc. We work with the customer to customize it for the ECUs communication specification. Apart from testing continuous engine parameters, Diagnostic Trouble Codes defined for the ECU can also be tested. Containing many building blocks of an actual ECU, for many communication tests the test station appears to the ECU as a peer ECU (sometimes multiple) of the related sub-system(s)!

Testmate can reliably simulate inputs to the ECU, ranging from the simplest ignition key switch to the complex crankshaft position waveform that is a critical input for many engine control functions. It also measures the ECU’s outputs, ranging from the discrete voltages or timed pulses to PWM waveforms to actuators, and evaluates it against defined limits for pass or fail. In addition to functional tests, power supply and other electrical (negative) tests can be performed to test how well the ECU hardware responds to abnormal conditions, like reversed polarity of the power supply, under voltage etc. The I/O instrumentation is completely custom-designed as per the interface specification of the ECU.

The HMI software supports multiple levels of users, with differential permissions defined for each login level, like running tests, modifying test parameter limits, changing the sequence of tests, error message text, test calibration and troubleshooting. All tests are logged for later review by supervisors or managers. For failed tests clear troubleshooting assistance is displayed/logged as to which specific test failed and how exactly, so that the defective unit can be repaired. An ECU may come in twice for tests, once after bare assembly without the enclosure, and once again after the enclosure is fitted.

Finally it all comes together in the hands of the operator, who after loading an ECU has less than a minute to run the automated tests to know if it is a pass or a fail. Pass is good news always, the ECU gets a bar-coded label stuck on it and moves forward to the next stage. However a fail is hardly the end of the road because in order to keep the rejection costs low failed units need to be repaired, with the test station providing precise troubleshooting information to get it repaired quickly. In this context a few pertinent questions for relevant Tier-1 Manufacturers and OEMs are:

1) How much of ECU test station design could be generic, versus how much of it should essentially remain ECU design specific?

2) Does it justify to their business to completely reinvent a unique solution to their challenge in terms of engineering effort, cost or timelines? While large parts of the challenge retain a commonality, which a generic test platform such as Testmate has not only abstracted, but also been customized for specific ECUs and proven on the factory floor.

At Deep Thought Systems, we clearly understand the generic and reusable parts of the TestMate platform which help accelerate the design of EoL Test Stations. A high-performance hardware platform, powered by a real-time operating system and sound embedded firmware design practices ensures fast test execution and that all timing considerations in vehicle communication protocols are taken care of. Thanks to our expertise in digital and mixed signal hardware design, we are able to quickly customize other parts of the test station like I/O interfaces, ECU fixture and HMI software as per the customer’s specification and needs with total assurance of the customer’s Intellectual Property.

Another closely related area for production where we could work with customers to provide a quick solution is the design and supply of ECU Flashing units. Operators use the flashing units to flash the firmware into ECUs after assembly. The design of the ECU flashing unit is greatly accelerated by our generic ECU flashing framework, where the only input required from the customer is the seed generation algorithm for unlocking the ECU, which could be imported into our firmware as a library (in binary form) to protect the customer’s (or principal’s) confidentiality. In conclusion, our expertise and track record of supplying and installing EoL test stations on factory floors and supporting production personnel in the usage and fine-tuning of these systems will ensure an efficient and trouble-free operation for the customer for the entire production lifecycle.

Link to Linkedin article

Crowdfunding- a boon or a burden to Tech Startups

These days we see quite a few technology companies going the crowdfunding route(Indiegogo/Kickstarter) to get to market sooner rather than wait for the traditional way of raising money to build the product. It appears as a beautiful idea if co-founders do not want to give out equity but raise money to get to market.  But I personally feel that this is a double edge sword and entrepreneurs have to be very careful with the choices as it may end up hurting more than helping in the long run.

What I have noticed is companies look forward to crowd sourcing mostly for either one of the following reasons

  1. Raise money to help them accelerate the engineering cycle time and help them reach market faster with confirmed orders  – The challenge with this usually is if you are not far enough into your engineering /product cycle with most problems solved the money raised through these campaigns are in most cases is not enough to get to production and delivery.
  2. Create a sales and marketing buzz which then later helps them to get leverage with retailers and opens up many channels – This is a fantastic model because getting into some of the traditional channels to sell a product is not easy. But these days Bestbuy/Amazon etc. have a separate focus on successful products from these campaigns. So this will enable the startups to get into shelf faster if they are successful. This also gives a better chance of getting picked up by some distributors.
  3. Show the demand the product has in the market to convince tradition VC’s to put in money into the company – This is a good idea only if you are convinced that your product is going to be a runaway success else the chances are that it can do more harm.  Any thing less than a runaway success is going to raise more questions and challenges when startups try to raise money than help.

I have read few statistics and based our experience, the projects mostly do not make it out in time. This ends up damaging credibility with the same customer base which supported the product. And now if the product turns out to be below par after a long wait, we have a very unhappy customer to deal with also.

What I noticed is that many of these companies fail to deliver on time because

  1. These companies are either trying to solve some really challenging engineering problems which need a tremendous amount of money than what they can get from a Kickstarter/Indiegogo campaign. So they start falling behind on development goals and delivery deadlines
  2. They have the right idea and concept but limited experience in delivering products end to end and when they start dealing with it they realize the unknowns are lot more than the knowns and they start slipping
  3. These companies are fighting battles on many fronts and crowd sourcing is just one of the avenues. So they do tend to get carried away in their engineering cycle when they see greener pastures which ends up adding delays.

My personal thought always has been crowd funding is a good platform if you are done with 80% of your engineering . As I mentioned earlier this is because the money you raise from pre-selling this product is usually good to pay for your production needs only. However, if you are planning on doing your core engineering and delivering product based on this money then the likelihood of failure and delays are very high. The only exception I can think of is if the company has a reliable partner/team in a country like India, China where a bulk of the engineering is being done then this money does tend to help even if they are behind in their product lifecycle.

I think backers need to check with the company before putting money in as to how much of engineering is already done and ask to show working prototypes, actual Industrial design mockups, software demos etc. before trying to put money in.  Also, it may help to ask how the money collected is going to be spent because it gives you an idea of the readiness of the product you are backing.

Link to article on Linkedin

Bringing home SAE J1939 Heavy-Duty Protocol Simulation

The J1939 standard for heavy-duty vehicles drafted by the SAE (Society of Automotive Engineers) in the mid-90s was driven originally by the “ECU trend” with the main objective of controlling exhaust gas emissions under increasingly tightening US and European regulations. Having gained wide acceptance ever since among diesel engine manufacturers, the SAE J1939 heavy-duty protocol has presently reached the stature of the de-facto standard for Truck and Bus manufacturers worldwide, for communication between various vehicle components and for diagnostics.

J1939 is a set of standards that includes a higher layer messaging protocol that works over CAN (Controller Area Network) protocol at the physical layer. The communication model supports both peer-to-peer and broadcast communication. The J1939 message format uses the Parameter Group Number (PGN) to label a group of related parameters, each of which may be represented by a Suspect Parameter Number (SPN). Continuously varying vehicle parameters (like Engine RPM etc.) are defined along with their valid range, offset, scaling etc. Besides, discrete (ON/OFF) parameters (like Brake Switch ON etc.) are defined separately. Commands to Enable/Disable specific vehicle functions (like Engine Fuel Actuator Control etc.) are defined.

Time based updates happen at 20 milliseconds (or lower) repetition rate, whereas the rate is significantly higher at higher Engine RPMs. Some periodic messages contain information that is of particular interest only when a specific state change occurs, and there is a defined range of repetition rates for these messages. Diagnostic messages (DMs) from various sub systems (like emission control etc.) are defined as per the Diagnostics Application Layer of the J1939 standard that includes services like periodic broadcasts of active DTCs (Diagnostic Trouble Codes), reading and clearing DTCs etc. Manufacturer specific parameter groups are supported that allow OEMs to define their proprietary message in addition to standard messages.

ECU design engineers of vehicle sub-systems at automotive OEMs, Tier-1 suppliers and R&D Service Companies routinely use J1939 Simulators for their product development, test and validation activities. In the early stages of development, a simulator comes handy for providing signals from other vehicle components exactly the same way as it would be in the real vehicle environment without the need for an actual vehicle in the lab. For instance a design engineer working on an ECU development program for Transmission Control would need signals from Engine Control system, Braking System etc. in order to validate his design functionality and performance. The ECU would get all these signals from the Simulator exactly as it would receive them in a vehicle environment, the physical connection provided by 2 CAN wires (CAN-HI and CAN-LO) and Ground (GND), taken out from the Simulator’s 16-pin OBD (or 9-pin D-Sub) connector using a custom wire harness to the mating connector of the ECU.

The J1939 simulator provides the design engineer with the ability to generate and vary individual parameters in order to check the response of the system under design/test. The required variations could be manually controlled using (rotary knob) potentiometers for continuously varying parameters. Some simulators automate the variation according to a pre-defined curve. A linear ramp that sweeps the full range (0-100%) of the given parameter, in increasing steps of 1%, is typical. Advanced simulators based on engine modeling data provide the ability to vary multiple parameters simultaneously in a specific relationship with reference to each other for better real-world simulation. A cost effective alternative to this would be to record multiple parameters of interest from the actual vehicle under standard test/driving conditions for the required duration, also known as the drive signature, and playing back the captured signature in the lab in the same time base, although with a lesser timing accuracy. Add on the simulation of actual vehicle hardware, like sensors, actuators etc. to create a fully Hardware-In-The-Loop (HIL) simulation and the full-extent of the simulation picture becomes complete.

Indian automotive R&D groups have traditionally banked on imported tools for J1939 simulation. Originating from USA, Canada, Germany etc. many of them come with pricey licenses although offering just an elementary 5-signal manual simulation. A few sophisticated ones with automatic ramp sweeps etc. are super-pricey, that even Indian R&D subsidiaries of multi-national OEMs have to contend with time-sharing the same simulator across multiple engineers/teams. It is in this context that a strong need is being felt for a high quality, cost effective J1939 Simulator that is indigenously designed and manufactured, that could provide many Indian customers the much-needed scalability for their R&D activities and reduce their dependence on imports.

Awareness on the availability of an indigenous product is the starting point however strict adherence to the standard is a hard requirement, including very strict timing considerations, in order to create a positive lean among automotive customers who always select and use only “proven technology”. Benchmarking data with reference to competing products could help customers get quantitative insights. Pilot trials could help them in familiarizing themselves with the indigenous product and to evaluate it against their experience with imported tools.

We at Deep Thought Systems design manufacture and supply J1939 simulators to Indian automotive customers, in addition to other offerings for CAN/J1939 logging, test/diagnostics, J1939 based displays and ECU manufacturing test automation. In our endeavors in bringing the above mentioned advantages to the Indian automotive R&D sector, we found that a customer’s need many a time is a highly customized simulator for their specific application. And thanks to our expertise in automotive protocols like CAN, OBD-II and J1939, and being fully in control of the hardware design, component sourcing and manufacturing as well as the embedded firmware and application development, we find ourselves well placed to deliver to these custom needs.

Post Scriptum:

A later industry development has been that all the major European heavy-duty OEMs came together in 2000 to co-develop the Fleet Management Standard (FMS) which is based on J1939 that incidentally opened up possibilities for manufacturer-agnostic telematics applications. The J1939 simulator, combined with suitable GPS simulation having the required levels of performance, offer telematics product designers a proven means to quickly test and validate their design well before going for in-vehicle tests.

 Link to article on Linkedin

Configuring headless systems

Ram Mohan Ramakrishnan

Ram Mohan Ramakrishnan

Headless systems abound in the embedded world, in consumer electronics, industrial automation, communications, automobiles etc. In these embedded devices, a Human Machine Interface (HMI) is conspicuous by its absence. That’s to say the device lacks a user display like a monitor, or LCD panel and nor does it have an input device like a keyboard/mouse or remote control.

Yet many of these systems need manual configuration by the user. The authorized user should be able to change certain operating parameters of the device within a predefined set of values. For instance, the Right/Left speaker settings in a home audio system, or safety thresholds in an industrial chemical reaction process, or DNS Server setting on a network router, or an engine speed/RPM limit setting on a telematics device etc.

User configuration circumvents the need to change the embedded software code (also known as the firmware) to address each and every individual user’s preference/scenarios. This would otherwise imply access to the source code (which in most cases is not open to users), making the required code modification, followed by compilation and re-flashing the updated firmware into the device. Configurability, the attribute that allows users to change key system parameters (that are internally used for computation by the firmware code) to predefined values at run-time, has traditionally been a critical design consideration for embedded system designers.

The user performs configuration settings usually using a software application that runs on a desktop or mobile device that presents the user with a configuration interface. The first generation of configuration applications (configuration files being their predecessors) ran on the desktop and used the serial/RS232 port, omnipresent at that time, to connect to the embedded device. These Apps were ported later on either to USB, which replaced RS232 on most modern computers, or ran as such by leveraging the virtual com port (a USB driver abstraction) that made the USB port appear as a normal serial port to the App. Examples of these applications can be found with printers, CNC machines, process control equipment etc.

After the World Wide Web established itself as a platform-independent paradigm for server access, the HTTP protocol came to be adopted across the spectrum of embedded designers for the purpose of device configuration. The inventors of the “www” may never have dreamed that the advantage they had created of not having to install a client application (and ending up managing multiple versions of client Apps for various OS/versions) would some day result in the creation of tiny embedded web-servers that run inside embedded devices. These are low footprint HTTP servers (like HTTPD) which make it possible for the embedded device to be configured using just a browser running on any platform. The IP connectivity typically being over either wired network like Ethernet, or wireless that is Wi-Fi or cellular (GPRS/3g), implemented as light-weight TCP/IP protocol stacks (a la lwIP) to run on resource constrained systems.

For instance, most telecom equipment, network switches, routers and gateways come with configuration pages that can be accessed using a browser. The first step in configuration typically is login, to authenticate user credentials and confirming the level of authority to perform configuration tasks. Subsequently a set of configuration pages are served out from a central menu, where the user can set/change specific parameter values for a group of configuration parameters related to IP networking, that are grouped together on that page. For enterprise routers, the configuration includes simple settings, like DHCP/Static IP, Default Gateway, Subnet mask, DNS Settings etc., but grow pretty complex, to Firewall/DMZ settings, Access Control, VPN/tunneling, Port forwarding etc. Thus it requires a qualified and experienced networking engineer to configure it correctly and to maintain the network equipment up and running.

Narrowing down focus to the world of consumer electronics, a few major industry trends seem to have influenced the way users configure headless systems in the home entertainment space today.

1) The ongoing explosion of mobile Apps, on Android, iPhone, Windows phone etc. – To such an extent that “there is an App for anything and everything”! This seems to have turned the tables on the earlier “browser” trend. Who cares for the browser now, there’s an App that does it anyway! And everyone knows it’s a song to just download/install a (whatever) App from the (which ever) Store.

2) The proliferation of home routers – With exploding popularity and plummeting costs, that the term “IP address” today is considered the tech-ABC of modern life. (In the 70’s the term “IP address” used to be high-tech parlance, but today it forms a part of the general vocabulary of a high school kid!) Since IP networking involves a highly standardized set of settings, like DHCP/Static IP, DNS settings etc., a home user can usually manage to set it up without much trouble. Or can at least leave the defaults alone knowing it is good enough to work correctly!

3) Wi-Fi gaining the status of defacto standard in consumer electronics – Thanks mainly to its cable-free, high bandwidth and moderately high range qualities, all ideal for the home segment. Given the massive penetration of Wi-Fi in homes today, networking for most consumer-electronics manufacturers defaults to Wi-Fi, although occasional segments of wired Ethernet could still be present in the home.

Streaming media protocols like Digital Living Network Alliance (DLNA) that work over self-discovery based networking protocols like Universal Plug-n-Play (UPnP) therefore work seamlessly over Wi-Fi, making it a natural choice for most device manufacturers, ranging from the traditional players like Sony, LG, Samsung etc. to recent innovators in this space like Google, Microsoft, Amazon etc. (*) These devices are far from standardized in their function, ranging from simple audio streaming systems, or gaming consoles to full-fledged home theatre systems. Some of these products come with Wi-Fi remotes and configuration (mobile) Apps. The important commonality is that these devices are all accessible on the Wi-Fi network, all the time.

So why configuration for a consumer electronics device! Imagine a user picks up the product from a store and brings it home, so how does the device know the user’s home network details so that it can connect? How could the user tell the consumer electronics device, “this is my network SSID, and this is the passkey”? – A mandatory and generic configuration that is valid for any make/model, for these are the vital pieces of information without which the device cannot join the home network successfully.

Further configuration needs will depend on the nature and functionality of the device. For instance, for a DLNA compliant device, what is the role of that device, whether is it a controller, or a renderer etc. Being non-standard and product-specific configuration settings, a browser based configuration process using menu-driven web-pages may not be intuitive to most home users. Hence custom Apps on popular platforms like Android, iOS etc. (available on the respective App stores for users to download and install) have become in vogue.

The user being a layman here (unlike in the case of a network switch where the user is an experience network administrator) the Config. App needs to provide a zero-learning, intuitive and wizard-driven experience. The Config. App needs to anticipate the user’s concerns, learning curve and proactively push help, like context-sensitive FAQs or “How to” videos, rather than let issues happen and then provide troubleshooting tips. As someone rightly said, “think not how you as an engineer would use it, but how your mom and dad would, and get it to work correctly too”!

The duration of time when the user is configuring the device is called configuration (or config) mode, whereas most of the time while in normal operation serving the home entertainment function, it is said to be in normal mode. To support the web server design pattern for configuration purposes, the device could be switched to become a Wi-Fi Access Point while in config mode. This means that the Config. App (usually a mobile App) can now connect to the device, and the user can set the configurations. Whereas for performing its normal home entertainment function, the device could be switched back to act as Wi-Fi Station, that normally connects to the home router/Wi-Fi Access Point.

Modern Wi-Fi chipsets (a la Broadcom) come with multiple mode operation – Wi-Fi Station (STN) and Wi-Fi Access-Point (AP) modes. Alternatively, a Soft-AP implementation on a single mode chipset would also serve the same purpose, as long as it can be made to switch between modes. The actual switching to config mode could be triggered on a special combo keypress (often with predefined timing) on the device itself. For instance, the Config. App of a consumer electronics device could display the following instruction to the user, “To enter Config mode, press and hold the FFWD and REV buttons simultaneously for more than 10 seconds. The Yellow LED will start blinking to indicate it has entered Config mode “.

From a connectivity view-point it is interesting to note that while in Config mode, the device loses its connection with the home network, since it is now acting as an Access-Point. With the mode switch it has started its own network for configuration Apps to connect, during which its normal functionality like rendering music is not available. It is sometimes even confusing to users, especially if internet access is involved, like Internet Radio etc.

Switching back to normal mode typically happens at reboot. Alternatively it could be implemented as the response to a reboot command while in Config. Mode. Following this mode switch the device regains its ability to play music etc. Another interesting behavior is that when this mode switch/reboot happens, the Smartphone loses its Access Point effectively so it automatically rejoins the home network to which it was connected earlier, a subtle yet standard behavior across Smartphones.

Since the embedded device and its Config. App have now become two peer Wi-Fi stations on the home network, it necessitates a mechanism for the App to know if (and when) the device rejoins the network after reboot. This could be implemented in the device using a broadcast mechanism of datagram messages, which the App could be programmed to detect with a suitable timeout.

Given the need for the Config. App to be available to users on multiple Smartphone platforms like Android, iOS etc. embedded system designers have adopted HTTP-based RESTful APIs as the programming interface to the embedded device. The embedded web-server is in fact a REST Server exporting REST APIs, which are implemented either as GET or as POST requests. The mobile Apps could call these REST APIs, with the data being exchanged as JSON payload of these requests. The embedded firmware that includes the REST Server is usually validated early on in the development cycle using generic REST API Clients (a la Chrome Advanced REST API Client), following which the Android and iOS Apps could be developed and hosted in the respective Stores.

Although not related to configuration, another generic scenario encountered with consumer electronics devices is firmware upgrade, or OTA (Over-the-air) upgrade as it has come to be known. The App typically alerts the user regarding the availability of the latest firmware, based on which the user decides to initiate the upgrade. The firmware image gets downloaded from a designated server of the manufacturer, typically an FTP server, file integrity check is performed after download, the firmware image is written into Flash, the boot loader parameters are modified and the device reboots (often more than once). All of this happens sequentially, silently under the hood, the App finally informing the user regarding the status of the upgrade.

The OTA feature also helps the manufacturer ship the hardware to hit the stores early, while allowing them to conveniently roll out updated features to users. So the next time we buy a device, like a fitness band, and install its App and it triggers off an upgrade (the first-time upgrade often being unsolicited!), we know what’s been happening! The App therefore forms a critical link in the whole upgrade process since the user needs to be kept in the loop always.

Configuration of headless systems has come a long way, the connectivity and Apps migrating across multiple technologies and platforms. In consumer electronics an increasing list of non-Configuration features are getting included in the Apps, such as firmware upgrades, library settings, playlists, favorites etc., making today’s consumer electronics products ever more user friendly and competitive.

(*) – While products from most home audio leaders like Bose, Denon, Yamaha etc. do support the DLNA standard, some of them are known to be moving towards proprietary APIs for media streaming and control. However they will most probably continue to leverage the underlying UPnP layer for device discovery, description and connection services.