×

Happy to Help!

This website doesn't store cookies. Enjoy the experience, without worrying about your data!

Great, thanks!

Monthly Archives: May 2018

  • May 30, 2018
  • 0

How Automotive ECU Consolidation is Powering the Multi-Display Infotainment System in Cars

Tags :

Category : Embedded Blog

While talking about the industries that have shown exceptional growth and fast-paced innovation, automotive industry definitely deserves a loud mention.

Not more than a decade ago, we ever expected our car to be a powerhouse of connectivity.

Thanks to the advancements in sensor technologies, robust in-vehicle networking, and smart automotive Electronic Control Units (ECUs), we are witnessing a new era of connected systems.

Information related to driver assistance, navigation, instrument cluster and access to phone calls/messaging are being delivered seamlessly to the driver.

All this data is delivered via different sources like CAN in-vehicle network, connected Sensors or through IP/GPS/Cloud connectivity

The need to display such critical data, provide ease of access and mitigate driver distraction led to the introduction of multi-display infotainment display. This is one system among the car’s components that has evolved very rapidly.

Let’s have a look at the story of evolution of Automotive Infotainment solutions over the years


EVolution of Car infotainment system
Image: Evolution of Car Infotainment system

It all started with a modest FM radio on the dashboard and now the modern in-vehicle infotainment system is evolving into a seamless multi-display system.


Old Stereo System to multi display system


Source: Carz2web and Lincoln/Continental

Introducing “Multi-display Infotainment Systems” for Cars!

The evolution of infotainment system in cars has now reached a point where one display does not suffice. The multi-display infotainment system has become the need of the hour.

Glimpse of the modern day vehicle cockpit

Most traditional infotainment consoles have been positioned at the center of the dashboard. Displaying information on this console needs constant attention of the driver away from the on-road viewing area. This has raised a concern regarding driver distraction.

  • In order to mitigate this, car head-up display has been introduced. Car Heads-up Display (HUD) sits just in front of the driver on the dashboard within the on-road viewing area.

  • Instrument Cluster can also be considered as one more display which helps driver to access critical vehicle data via CAN in-vehicle network.

Traditionally all these display systems (Infotainment, Head-Up Display, Instrument Cluster) work in silos. They are powered by separate Automotive Control Units (aka ECU), have independently designed UI/UX, fetch data from respective sources and are very likely to be developed by separate automotive suppliers.

Glimpse of the advanced Tesla-like vehicle cockpits

Welcome ‘Multi-display Infotainment system’, which is powered by a single Automotive ECU (single hardware) and has one central processing unit.

This central hardware & software system works as a hub that projects the output on multiple displays; viz; Car Head-up Display or Windshield, Digital Cluster, Connected Mobile phone and more.

How Does a Multi-Display Infotainment display system Work?

A typical multi-display infotainment system would essentially feature the main unit (infotainment system) and an Automotive Heads-up display. Additional displays such instrument cluster can also be added.

Features such as navigation, vehicle diagnostic information, media playback, voice control, gesture control are some mainstream inclusions in a new age infotainment solution.

The key components of a multi-display infotainment system:

  • A Robust Processor that can handle multiple displays
  • Operating System (Android Preferred)
  • CAN, LVDS and other network protocol support (As per the requirement)
  • GPS, Wi-Fi, and Bluetooth Modules
  • Sensors for detecting ambient light, gestures, proximity and more.
  • Integrated Head-up display

The ones enlisted above are the basic building blocks of a multi-display infotainment solution. More tailor-made and an advanced solution may require additional hardware and software components.

We will now discuss the system details and see how these components interact with each other to provide information + entertainment (= infotainment) to the end-users.

  • The main board which can be called as the consolidated ECU (or automotive control unit), will be connected to the primary touch display (infotainment display) as well as the head-up display. The info that will be relayed to the infotainment display is usually pre-defined. On the other hand, the info to be displayed on the integrated head-up display can be chosen by the users.

  • The main hardware unit will identify the infotainment display as the primary one and head-up display and instrument cluster as secondary and tertiary display systems.

  • The highlight is a single brain that controls all the displays. Inputs such as voice commands, gesture, connected mobile phone etc. will directly go to the main unit. The main unit in turn, will process the input and send the output to the relevant displays.For instance, the navigation data should be sent to the head-up display as it is in front of the driver. Information that does not need immediate attention like the song playlist etc. will be shown on the infotainment display.

Again, it must be pointed out that the kind of information shown on different infotainment displays may vary in different products designed by various automotive OEMs/Suppliers.

Delivering a seamless user experience with multiple infotainment displays at work is not an easy task to execute. In the next section, we talk about the one of the major challenge that automotive engineers face with multiple display infotainment system- too many automotive ECUs to deal with.


Automotive ECU Convergence
Representative block diagram of multi-display infotainment system

The Need for automotive ECU convergence

There is an array of sub-systems in the car that need to be responsive, interactive and secure, all at the same time. As a consequence, the new age cars have a gamut of electronic control units (ECUs).

The introduction of multiple infotainment displays in the vehicles is not only increasing the number of control units and is also making the entire system very complex.

Also, data is being collected not only from traditional sources like CAN in-vehicle network, but also from deployed sensors and IP connected external environment. Hence deploying just one display will not only make the entire UI very cluttered but will also impact the end-user experience.

This situation is akin to handling a double-edged sword; we are in need of a solution that delivers a distraction-free user experience and does away with complexity of too many E/E systems.

The answer is ECU convergence or consolidation– whatever you may like to call it. Now let’s dig a little deeper.

“It will be tough for the OEMs to fulfill consumer’s expectations, both in terms of cost and quality, if every new feature in the car would require new ECU to be added”

A Few Pointers that Highlight the Need for Automotive ECU Convergence:

Consistency issue due to different automotive ECUs

Most automotive OEMs source automotive control units and other hardware/software components from different suppliers. In such scenario, keeping the user experience seamless and consistent becomes a challenge. This is one of the reasons why automotive OEMs are switching to a single ECU that supports multiple functions, thus aiding in creating a holistic and consistent user experience.

Maintaining the accuracy of the content displayed on the screen

The amount of content that OEMs want to display on the screen is increasing quite rapidly. In such a scenario, the device drivers need to coordinate amongst them to pass on accurate info to the displays. It is good to manage the content from a central hardware to keep any anomaly at bay. Also, when a display is showing some safety-critical information, the latency issue also needs to be minimized.

A consolidated automotive ECU that can handle multiple displays is the need of the hour. Innovations in the chipset design and development is making it possible for one Electronic Control Unit to handle multiple functions.

More ECUs means higher cost

Every time a new automotive ECU is added to support a new feature, it entails increased cost. Using different hardware platforms for the multiple displays results in a lot of overheads.

The procurement team has to coordinate with multiple suppliers. Also, every hardware needs to be validated and certified prior to deployment. Both time-to-market and cost increases as these processes involve series of testing and validation processes.

Vulnerability of the ECU system

Reports by Consultancy.uk suggest that by the year 2020, 80% of the new vehicle will be connected to the digital services. This raises serious security concerns.

Having multiple ECUs is similar to having multiple doors in the house. The burglar can look for the least secured door and breach the system. Moreover, securing multiple ECUs again escalates the cost.

When there is a single automotive ECU at play, securing it becomes easier and more cost-friendly.

Some people are of the view that a single ECU controlling multiple displays increased the vulnerability of the system. A successful breach into the central ECU will grant the entire access to the hacker.

Agreed! One cannot simply rule out this possibility and advocate fool-proof security of the single automotive ECU system. However, a consolidated ECU will localize the security issue to a single ECU.

Very strong security measures can be deployed to make it safe and secure. Also, the cost and time involved in securing the system will come down.

Get ready for a Multi-display Cockpit Experience in a Car

Multiple display system is now being embraced by many automotive OEMs worldwide. As ECU convergence gains pace, we can expect to see more cars and some even in the budget segment to come equipped with a multi-display infotainment system. The driving experience is definitely going to be very rich with such as system.

  • May 24, 2018
  • 0

Unraveling the Story of Evolution of IoT and Its Rapid Adoption

Tags :

Category : Embedded Blog

IoT is no longer a new kid on the block and has paved a journey so eventful and so successful since its invention, that today IoT is one of the topmost business growth drivers.

So, isn’t it interesting to know how IoT has evolved over the time to be in the mainstream business today?

This blog is a humble attempt to understand that.

The Need for M2M Connectivity had Always Been There..

Though the concept of connecting the machines or the physical systems have been a subject of interest for the technology innovators for quite a long time and various inventions  have been made in this regard.

For a very long time, RFID was being used by the manufacturers of consumer goods and retailers on the shipping pallets for easy inventory management. Though at that time, “ IoT” as a term was never envisaged, the basic context of having various physical systems communicate with each other over a distance in order to improve operational efficiency had always been the objective.
 

RFID to IoT
Image: From RFID to IoT. Image Credit: mojix

Yet, the breakthrough came with the idea of reinventing RFID into a networking technology by the MIT professor, Kevin Ashton, who coined the term Internet of Things (IoT).

Once the IoT began to be used for integrating such approaches (connecting and remotely monitoring various entities) into a common framework, there has been no looking back.

The Chicken and Egg Analogy

Thus it would not be wrong to compare the evolution of IoT from RFID with the chicken or the egg causality dilemma.

Though IoT as term was coined by Ashton, to represent linking of physical objects through RFID, but the idea of connecting physical systems has existed even before.


Evolution of IoT

Image: Evolution of IoT is analogous to the chicken-egg dilemma: Image credit: Pinterest

The Gradual Evolution of Internet of Things (IoT)

Let us have a look at how the evolution of IoT as a concept happened over a period of time along with the timelines:

Year 1999: Kevin Ashton , co-founder of the Auto-ID (for Automatic Identification) Center at MIT coined the term “Internet of things “. His definition of IoT was based on reinventing RFID as a networking technology by linking objects to the internet using the RFID tag.

Ashton’s vison was to create a system “where computers would be capable of gathering data without human help and render it into useful information, which would be possible with technologies like sensors and Radio Frequency Identification (RFID) that enable computers to observe, identify and understand the world.”

Year 1999: Device to Device (D2D) communication as a concept was coined by Bill Joy as part of his “Six Webs” framework at the World Economic Forum.

Year 2000: LG Internet Digital DIOS, the first Internet-connected refrigerator in the world was invented. The refrigerator used a LAN port for IP connectivity.

Year 2001: David Brock, co-director at the Auto-ID Center, MIT,  proposed a new object identification scheme, the Electronic Product Code (EPC), instead of the conventional Universal Product Code (UPC or ‘bar code’) for unique identification and tracking of objects throughout the product life cycle using the infrastructure/internet.”

Year 2003: The  “Project JXTA-C: Enabling a Web of Things” is published by Bernard Traversat and team at the 36th Annual Hawaii International Conference.

According to them, the Project JXTA’s aim is to specify a standard set of protocols for ad hoc, pervasive, peer-to-peer computing as a foundation of the upcoming Web of Things.

Year 2003: A special kind of network to connect many of the millions of tags that are already in the world was launched at the McCormick Place conference center.

The launch of electronic product code (EPC) network was attended by numerous delegates from across the worlds of retail, technology and academia.

Their aim was to replace the global barcode with a universal system that can provide a unique number for every object in the world. Some have already started calling this network ‘the internet of things’.

& some more parallel inventions and experiments later…

 Year 2005: The faculty at the Interaction Design Institute Ivrea (IDII), Italy, invents a single-board microcontroller to be used in interactive projects being developed their students.

Later in that year, the International Telecommunications Union published a report titled “The Internet of Things”, one of the 7 part report on internet.

Year 2008: Different industry stakeholders come together to form the IPSO Alliance to promote connected devices. This was a big leap towards having the IoT implemented for large scale business in real production setups.

2016 and Beyond: We have connected home, connected cars, IoT enabled manufacturing plants, and IoT based solar trackers.

Internet of Things has spread its wings across the industries and a newer term “Enterprise IoT (EIoT) “ has been established that includes devices used in business and corporate setups . As per the market experts, there would be about 50 billion connected devices by 2020.

Although, the definition of IoT has changed from what Kevin Ashton had envisioned it to be with numerous technology inventions, the founding principle of having a network of interconnected devices that are interacting with each other and the surroundings to collect and analyze  information using internet has remained the same.

Over the time the RFID based IoT model failed to gain enough attention due to limited connectivity option, high cost of devices and infrastructure. Plus, the RFID based system was not deemed fit for large scale production set up such as the industrial automation. But IoT continued to evolve due to advancements in IP based network connectivity and various other technical innovations that made M2M connection possible over broader range.

The Hows and Whys of Rapid Adoption of IoT

So far we discussed about how IoT has evolved step by step , over a period of time. However, this discussion will be incomplete without looking at the key factors that has led to the rapid adoption of IoT across the industries today.

Some of the key drivers of the widespread adoption of IoT across the industries can be summarized as:

  1. Advancement in Connectivity and network capabilities
  2. Improvement in cloud computing
  3. Invention of Data analytical tools and rapid improvement in data handling capabilities
  4. Availability of low-cost devices, plus reduced computing and memory costs.

Advancement in the networking capabilities– Today, there are numerous wireless technologies available in the market that enable communication among devices.

Some of the widely used networking technologies range from Wi-Fi to Bluetooth, from ZigBee to Z-Wave, from DECT  to Thread. In addition to these, AllSeen, DLNA, and UPnP , the peer-to-peer communication technologies are enabling direct device connectivity without the need for an access point

Improvement in cloud computing: The rapid improvement in the cloud capabilities has been a significant factor in making IoT so accessible and widespread.

That’s because the cloud provides a low-cost, and an always-on place for storing and processing data/ information.

Availability of affordable cloud infrastructure has facilitated seamless offloading of storage and computing related tasks onto the cloud servers from the IoT devices. This in turn has made it easier for many industries to embrace IoT faster. Today, IoT and cloud are inextricably linked and are implemented to simplify complex business problems.

Reduced costs – The availability of low cost sensors along with gradual decrease in the cost of connected devices has helped businesses- both mid-size and small scale ones –  to look at IoT as a viable technique.

Thanks to the numerous technical advancements made over the year, today the computation costs, the memory costs and wireless connectivity costs all have been made affordable for more users.

Advancements in data handling and analysis – Over the past decade, data handling as well data analytical capacity has improved by manifolds. Data collection and analysis being the USP of an IoT based system, advancements in data analytics has definitely opened up newer IoT use cases.

Today there are multitudes of connected devices that interact and exchange humongous volumes of data – that too in varies data formats.

The magic of converting data into actionable decisions and to make revenue out of them was possible with the advent of Big data based analytical tools.

Adoption of Internet of Things

Image: The IoT adoption and Big data connection;  Image credit: IEEE

Numerous data analytics techniques such as Spatial Analytics, Time Series Analytics, Streaming Analytics are being used to analyze the data which vary both in formats and structure (structures and unstructured data, Location based data and time based data..).

Thus, advancements in the field of data analytics has not only helped business in widespread adoption of IoT, but also opened up newer opportunities to create and scale business.

In addition to these factors, the rapid adoption of IoT has been made possible by:

– Improvements in areas like data traffic, storage and processing capacity, data volumes & more..

– Invention of newer standards enabling connectivity between IoT hardware and software from different providers.

Concluding Thoughts:

Like the legendary quote that goes like “Rome was not built in a day”, the evolution of IoT too evolved gradually over a period of time, with numerous parallel experiments being undertaken.

Though IoT’s beginning can be traced back to the Ashton’s RFID experiment at the MIT’s Auto ID Centre, the modern IoT is a convergence of numerous technologies such as cloud computing, wireless communication, data analytics among many others.

  • May 23, 2018
  • 0

Woocommerce vs Magento Commerce: Which eCommerce Platform is Best for your Online Business?

Tags :

Category : Digital Commerce & Experience Blog

Choosing between Woocommerce and Magento is a tough decision-making task for companies / individuals, who plan to start an ecommerce business.

Both the platforms, for ecommerce development, offer rich features and are very popular among the ecommerce developers community.

In this blog we will discuss the features such as setup, security, performance, community support of both the platforms. The objective of this blog is to serve as an evaluation guide for you in order to help you select the more suitable ecommerce platform.

Woo commerce
 
Key Difference

Woo Commerce Magento Commerce
Woocommerce is a plugin for the wordpress platform.

WordPress is built as a content management system and Woocommerce works on top of this content management system.

It has all the features required to build a simple ecommerce web-store.

 MagentoCommerce is a platform which is built just for ecommerce websites and supports lot of customizations to develop a robust ecommerce store.

Magento can be used to build ecommerce websites from simple to complex ecommerce store.

Community Support

Woocommerce and Magento are backed by huge community of users. There are plenty of plugins/extension available (both free and paid) to enhance and improve the features of the ecommerce store.

Brainstorm the functionalities required for your web-store and evaluate the available plugins/extensions that can help you to implement the ecommerce website requirements

Do check if the shortlisted website plugins are available free or need to be purchased.

Magento Marketplace
Magento marketplace has 3521 extensions to power various critical features and functions of your ecommerce website.

Magento marketplace
 

WooCommerce Plugins
Magento marketplace has 5404 plugins available to enhance your ecommerce store.

Wordpress Plug-in
 

Initial Setup

Woocommerce is a perfect solution for beginners who want to develop an ecommerce website with basic features. The installation is very easy, as most of the hosting providers provide one-click wordpress installation and you just need to add the Woocommerce plugin to get started.

Woocommerce has plenty of tutorial videos available, these serve as a good installation and development guide.

Magento comes with a full installation wizard that makes it really easy to install and get started with the ecommerce website development. However, one may require expertise and guidance of a Magento Developer or Consultant for best results.

Magento also has plenty of tutorials and documentation available to make your job easy.

Pricing and Business Model: Magento Commerce v/s WooCommerce

Budget is a huge factor in deciding between both the platforms. Woocommerce plugin is completely free of any license cost.

Magento offers a ‘Community Edition’whichalso doesn’t involve any license cost. Apart from the Community version, Magento also offers ‘Enterprise Edition’.

Enterprise Edition of Magento is loaded with rich features and functionalities, which are not available in the Community Edition. This is very critical for an expanding business looking to scale-up the operations. As a business, one may start the ecommerce website development on Magento Community Edition, but may feel the need to upgrade to the premium Enterprise Edition in few years.

The premium plugins and extensions for both platforms can be bought from their respective plug-in marketplaces. Premium extensions for Magento are quite expensive compared to the Woocommerce plugins.

Hosting for woocommerce website is relatively cheap compared to Magento ecommerce website. Since Magento is feature rich, you need to choose your hosting provider carefully to make sure that your ecommerce website is secure and optimized for speed.

Overall, the pricing for both the platforms is relatively less for small-scale  ecommerce stores but as your business grows and the requirement for the store grows, Magento (which is better poised to support the requirements) is expensive compared to Woocommerce platform.

Ecommerce Website Themes

WordPress has plenty of themes which are compatible with Woocommerce websites and has a huge pool of ecommerce developers who offer theme templates and integration services for woocommerce websites.

On the other hand, Magento’s community also has good number of feature rich website theme templates and support for integration.

Here’s the total number of themes available in themeforest’s website for Woocommerce and Magento Commerce platforms.

Total Number Themes for Woocommerce:  7238
Website theme

 

Total Number Themes for Magento Commerce: 1023
Magento Theme

Page Load Speed of your Ecommerce Website

Page load speed has direct impact on your website traffic and sales conversions. Google’s algorithm tends to favor websites which load faster. An ecommerce website with good page load speed also enhances the user experience.

There is no clear winner in this category, as the performance of both Woocommerce and Magento Commerce websites are affected by many factors such as web hosting provider, CDN and size of images.

To get an optimal result for your website built on any of these platforms,make sure you have all the basics covered.

Security

Ecommerce Website security it is the top priority for all the stakeholders. Customers expect the ecommerce store to protect their personal information as well as the payment details.

Woocommerce and Magento commerce platforms take several security measures to make sure that their code base is secure and protected from the hackers. Both offer many extensions to implement additional security measures.

In the recent times, wordpress based websites have been more prone to malware attacks and this has impacted the woocommerce websites as well.

Magento Commerce is more advanced as compared to Woocommerce in case of robustness of security measures.  Magento ecommerce platform provides dedicated security patches. You can find the latest security patches here.

Which eCommerce Platform is More Popular?

We tried to understand the popularity of both Woocommerce and Magento Commerce with the help of builtwith’s analysis tool.

Magento is used by over 655K websites and Woocommerce is used by over 2287K as of May 2018.

Popular

 

Top Websites by Ranking

When you look at the Top 10K websites as evaluated by “Quantcast Top 10k” list; the number of both Woocommerce and Magento based websites  that make this list is more or less equal..

 101 Magento Commerce websites and 109 Woocommerce websites feature in “Quantcast Top 10k”

Quantcast

 

Ecommerce Platform Marketshare: Woocommerce Vs Magetno Commerce

Below is the marketshare of ecommerce platforms based on the stats from Builtwith, as you see Woocommerce holds 11% marketshare and Magento holds 7% of the total ecommerce marketshare.
Woocommerce VS Magento
 

The Final Verdict

Picking between Woocommerce and Magento is easy when your requirement is clear. Woocommerce and Magento are easy to setup and easy to integrate. Consider your business requirement, budget, scale of operations and security before choosing a platform for your ecommerce store.

Woocommerce is good for websites with fewer products and for beginners as it’s relatively easy to integrate and offers easy-to-manage admin features.

If you’ve a clear roadmap and plan to scale-up your ecommerce website over a period of time, it’s good to start with Magento Community Edition.

Magento is highly scalable and is designed to support complex features needed for an expanding ecommerce business. Unlike Woocommerce, Magento can be easily integrated with Paypal, Authorize.net and Braintree without any help from external extensions.

Go For Magento Go For Woocommerce
If you need a highly scalable, robust, secure ecommerce platform If you need a simple ecommerce website which is easy to mange

We hope you have found this guide on Woocommerce Vs Magento useful. Still confused, book a free consultation with your ecommerce development experts and we will guide you to choose the right platform for your needs.

 

  • May 18, 2018
  • 0

Off-the-Shelf v/s Custom Developed IoT Gateway Solution: Factors That Will Help You to Resolve This Dilemma

Tags :

Category : Embedded Blog

As a key decision maker of a scaling business that is seeking to embrace IoT, you might have faced the dilemma of choosing between a build v/s buy strategy w.r.t IoT Gateway Solution.

“Custom solutions are the trend in the market. Customized IoT gateway solutions will be ideal for you to achieve your business goals and increase ROI. You should go for customized IoT gateways” says some.

“You can never go wrong with the Off-the-shelf IoT gateway solutions – It is the tried and tested method already being used by your peers. “say others.


But in such a noisy and confusing situation, how do you know which solution is ideal for your business?

In this blog, we will do a comparative analysis between the two investment strategies for IoT gateway solution and help you choose the one ideal for your business.

Making That One Important Decision

More often, the key factors driving the businesses to go for a particular solution include:

  • The implementation cost
  • The return on Investment (ROI)
  • How does it address your business challenge while being cost-efficient

In addition to these, before deciding and going ahead with your choice, it is important that you look into how each of the strategies fare when analyzed through important business and technical parameters.

Let us look at what these key parameters are.

Analyzing the Key Business Parameters:

  1. Per unit Cost:

    2. As a general rule of thumb, it has been observed that cost per unit of custom developed IoT Gateway is less than that of the off-the-shelf solution, only if the volume of IoT gateway units is very large.

    Large volumes ensure that the overall BOM cost of the IoT gateway design reduce due to the bulk purchases from all the component suppliers. Production of large volumes of the IoT Gateway Units also results in per unit cost savings in form factor and also software/hardware development.

    While the IoT Gateway devices bought off-the-shelf, in large volumes, would never be able to match such cost savings and per unit cost is most likely to be always higher.

    In contrast to this scenario, let’s say your business decided to first develop a prototype of the IoT automation systems. In that case, cost per unit of the custom built IoT gateway solution is always going to be higher than the available off-the-shelf IoT solution.

  2. Ease of implementation:

    3. Custom built IoT gateway solution will be developed by your IoT partner after considering all the use-case scenarios, your business automation goals, end-user challenges and the future scalability.

    Such a solution will be more close to the ground reality and would have been developed by considering all the interoperability challenges that you may encounter during the deployment.

    Contrary to the build strategy, an off-the-shelf IoT gateway device may throw up some surprises by way of the interoperability issues during system integration and deployments.

  3. Closer to the Business Goals:

    4. The custom developed gateway development is designed, prototyped, and developed following an iterative process of feedback and evaluation based on your business requirements.
    Add to it the freedom to make changes in the product, that a custom developed option offers.

    The off-the-shelf IoT gateway solution, on the other hand, will have a more generic design that may have been design for a range of industry domains (like Home Automation, Industrial Automation, Renewable Energy, Enterprise Battery Management and more).

    Hence, a custom developed IoT solution is more aligned towards your unique business challenges and goals.

  4. Ownership of the IP Rights:

    5. One of the biggest advantages of a custom developed IoT gateway is that as a business, you own the IP rights of the IoT Gateway product design.

    This means that you can always reuse the existing product components to upgrade the IoT gateway hardware or software, scale-up your operations in future, by deploying more IoT gateway devices (at similar or lesser per unit cost) and have control over the regular firmware and security patch updates.

    On the other hand, investing in the off-the-shelf IoT gateway product renders you dependent on your IoT gateway vendor, for these decisions and activities.

    In the worst case scenario, the IoT gateway company may decide to withdraw the product support or for some reason is unable to perform the required upgrades or maintenance activities. All this can have a direct impact on your business operations.

  5. Conditions Apply**:

    6. Sometimes, an off-the-shelf IoT gateway vendor may try to cross-sell and bundle the IoT Gateway product with in-house or 3rd Party Cloud Hosting Services.

    Such a bundled solution may not fit the bill in terms of both cost and features.
    On the contrary, with a custom developed IoT gateway, you can choose a cloud (and other associated) service that best fits your requirement and cost parameters.

  6. Time to Market:

    7. This is a no-brainer- The off-the-shelf IoT gateway supports immediate deployment and decommissioning. Hence the buy strategy ensures reduced time-to-market.

    The build strategy, on the other hand, delivers benefits if executed as a long term strategic investment.

  7. Need for an Expert Software and Hardware Team:

    8. Once your business decides to invest in a long-term IoT strategy, it becomes necessary to either build in-house IoT software and hardware development team or partner with an expert IoT services provider.

    This ensures that you achieve the desired organization goals and RoI.

    However, if the decision is in the favor of ‘buy’ strategy and not ‘build’ strategy, that your organization may opt-in for support and maintenance contract with the IoT gateway device vendor. One can also build a small-size in-house team for maintenance activities.

    The table below summarizes the points we have discussed so far:

    Key Considerations Off-the-Shelf Custom Developed IoT Gateway
    Time To Market Less, as the product is ready to be deployed More, as it needs to meet all the customization requirement
    Degree of ownership ( IP Rights) Is  majorly with the IoT solution provider  You are the owner of the final product design
    Support and Maintenance As per the terms and conditions of IoT Gateway Vendor Can be negotiated and tailor-made before signing the contract.
    Prototype Development Best suited for prototype development using standard hardware and software components Not feasible due to high cost per unit.
    Competitive advantage Lesser time to market, Freedom to add features you like
    Include and pay only for the features that you need<

Significant Technical Parameters to be taken care of:

While the above mentioned business parameters are quite applicable to off-the shelf vs custom developed solution predicament, what makes the scenarios unique are the technical parameters.

As a business organization looking to invest in an IoT solution, it is important to calibrate the following technical parameters and how well your business can adopt to these parameters:

  1. The Hardware:

    2. An off-the-shelf IoT gateway solution usually comes with hardware and peripheral components that are suitable for a range of use cases. This means for a particular function there might be multiple hardware features.

    For example, an off-the-shelf might have multiple connectivity modules integrated on the board like Wi-Fi, Zigbee, 6lowpan, Bluetooth and more.

    But it may happen that though you end up paying for all the features, but after deployment you only use handful of these functionalities

    To avoid this, your business may decide to invest in a ‘build’ strategy. This would sometimes mean that you don’t have to spend extra money on hardware components for features that you might never use.

    Please do note that now many off-the-shelf IoT Gateway vendors are also offering limited programming access. This enables you to configure and deploy functionalities that your project requires.

    However, this might increase the overall development cost

  2. Communication Protocol:

    3. The ready to deploy IoT gateway solutions that are available today support a number of wired and wireless connectivity protocols,  such as ZigBee, Z-Wave, LTE, Thread, Wi-Fi, RFID etc.

    Your specific IoT use-case may call for a more powerful connectivity protocol that is both reliable and secure, and can better communicate with the equipment within the network.
    Also, you might need a combination of Northbound (Wi-Fi, LTE, and Ethernet) and southbound connectivity (ZigBee, Z-wave, LoRaWAN, Thread, Sub-GHz) options.

    In such a case it is better to choose a custom developed IoT gateway solution rather than readily available ones.

  3. Compliance and Certifications:

    4. The most important part of the IoT gateway development process is to get the gateway certifications (FCC/CE/IC) on time. There are also certain pre-compliance considerations that need to be considered.

    This can be a bit challenging if you are getting the IoT gateway custom developed. You need to ensure every module that goes into your customized IoT gateway is certified.

    You must also avoid instances of incomplete compliances and certifications which might affect your product deployment. . All these processes can be painstaking and lead to more time to market.

    Meanwhile, the off-the shelf IoT gateway vendors most often have all these pre-compliance processes completed and they certify the product before releasing to the market.

  4. Form factor:

    5. The readily available IoT gateway has a fixed form factor. Hence you cannot expect it (the off the shelf device) to adapt and accommodate your specific requirements, if any.

    With the custom made IoT gateway, you have the freedom to decide the form factor design. This is particularly important when your operating environment is open solar fields or if it is an enterprise-wide deployment.

“A ‘build’ strategy gives you the freedom to develop an IoT solution tailored for your project goals. On the other hand, with the ‘buy’ strategy you might have to be flexible with your goals in order to get the best out of the solutions available in the market.”

Sujith_Vasudevan

Sujith Vasudevan, Technical Lead, IoT

To conclude:
In addition to these technical considerations, it is important to identify your business priorities before making the decision. For this, you might want to ask yourself some important questions such as:

  • Are ROI and cost savings more important for you?
  • Are IP ownership and customized solution, the most prominent factors?
  • Is a strong and secure network connection more relevant than using readily available options?

Once you have listed down your priorities and requirements, then it will be easier to make a decision that best fits your business context. It is also advisable to prepare an IoT development road-map so that all the stakeholders are in sync with the bigger picture.

  • May 14, 2018
  • 0

A Comprehensive Checklist for Evaluating an Off-the-Shelf IoT Gateway Solution

Tags :

Category : Embedded Blog

‘Internet of Things’ has ushered in an era where every organization is moving towards IoT-powered automation. This has resulted in many big players to introduce their range of IoT gateways and other IoT components.

Today, there are some really innovative IoT Gateway solutions available off-the-shelf. These IoT Gateway devices, launched by popular brands like Dell, Intel, HP, Cisco and more, are loaded with necessary features and functionalities.

This means that as a procurement manager or a business owner, who wants to make the system and processes IoT enabled, you are spoilt for choices! To overcome this dilemma, you need to look inwards.

It’s good to start by asking a few question to your IoT expert. What are the connectivity protocols your project requires? What about the environmental conditions your gateway will be exposed to? What are the security requirements? and so on.

Your IoT project requirements and business use-case will have direct influence on your choice of the off-the-shelf IoT Gateway solution.

Please note that your IoT use-case may also require you to completely ditch the off-the-shelf option and partner with an IoT gateway development vendor for a custom-made solution.

However, in this blog we will only focus on the off-the-shelf IoT Gateway solutions. We will highlight some important factors that are critical for selecting the best off-the-shelf IoT gateway for your automation project.

Key Functionalities to Look Out for, in an IoT Gateway Solution

An IoT gateway must have certain features that are critical in making your system and process automation IoT enabled.

A few of them are:

  • Support for Multiple connectivity protocols like Zigbee, 6lowpan, Wi-FI, Bluetooth, Ethernet and more
  • Secure communication, with built-in and robust encryption, user authorization and authentication processes, tamper detection and more
  • An IoT Gateway solution that is Hardware/Operating system agnostic and scalable
  • Support for data storage in gateway, to recover from a communication failure
  • Optional advanced features such as EDGE Computing, data filtering, configurable data rules, analytics and more.
  • Automatic device discovery along with device verification and authorization features.

In addition to these basic functionalities, there are certain specific factors that need to be considered while choosing the IoT gateway device.

The next section delves a little deeper. So brace yourself for the ultimate IoT gateway checklist coming your way!

8 Critical Factors to Help You Pick the Perfect IoT Gateway Device

The most suitable IoT Gateway development, configuration and specifications will completely depend on your IoT projects use-case and industry application (as mentioned before).

Your IoT project use-case will have a say on factors like number of IoT sensor nodes or IoT devices that need to be connected to the gateway at a given time, local storage required, packet data size and more.

We will evaluate the following factors on the basis of some real world IoT use-cases and eventually share with you an approach that will help you to take the right decision

  1. Array of Connectivity Options

    2. Connectivity is at the core of any successful IoT project implementation. An IoT Gateway device may offer both wired and wireless connectivity and can be chosen based on the specific project requirements.

    Some IoT projects that call for ubiquitous coverage and remote installation, eg. solar tracking systems, require IOT gateway devices with LTE and other cellular connectivity support.

    For IoT applications that require high bandwidth and maximum reliability, like predictive maintenance, lighting systems and Home automation, connectivity options including Ethernet, Zigbee, Wi-Fi, and Bluetooth should be supported by the IoT Gateway solution.

    The challenge of Interoperability also comes into play when we talk about the communication protocols. An IoT gateway solution may need to communicate with multiple IoT sensor nodes that are all developed on different communication protocols. An IoT gateway must be equipped to handle such scenarios of interoperability.

  2. Robust Security Provisions in the IoT Gateway Device

    3. In this age of connectivity, all your systems and process hold treasures of data. Data is the new ‘oil’ as it is the most crucial asset for your next wave of growth.

    Whether it is home automation or vehicle tracking system, huge volume of data needs to be sampled and interpreted for any analysis.  Data leakage can lead to privacy issues or corporate leak.  Protecting sensitive data from a leak is of paramount importance for any organization.

    When you decide to buy an off-the-shelf IoT gateway solution, you need to make sure what kind of security certificates and security programs are part of the solution or can be installed.

    Instances such as denial of service attack (DDOS), tampering, spoofing and elevation of privilege are some of the most common attacks that are launched on IoT systems. IoT gateway device is the most targeted component owing to its higher processing power.

    Market-watch: ARM CortexTM-A9 / A8 / A7, CISCO 9 series are some of the good IoT gateway devices to choose when security is a major concern.

  3. Low Power Footprint and Greener Power Source

    4. An ideal IoT Gateway solution should be developed for running on low power footprints. The gateway design should ensure reliable operation and should have capabilities to adopt ideal power saving options.

    This is because some of the IoT field deployments require IoT gateway devices to work on alternative power sources. This is to ensure cost saving in the long run and achieve the desired project RoI.

    For instance, an IoT gateway deployed in a solar power harvesting project should be able to run on the solar power generated by the solar panels already installed.

    MarketWatch: In case your IoT application requires gateways to be low on power footprint, you can go for gateways like AirLink® Raven RV50 gateway device that claims to be the lowest-power industrial IoT gateway. There are various other low-power IoT gateways as well such as ET01-868-UART, KBox A-201 mini Box-PCs etc.

    AirLinkR RV50RV50X Industrial LTE Gateway

    Source: Sierra Wireless

  4. Operating Environment

    5. IoT gateway devices, deployed in fields or other operating environments, may have to withstand harsh weather and environment conditions.

    For instance, an IoT system deployed in the sea for oil drilling companies will have to bear corrosion due to salt water and also the buoyant force of the sea water.

    Some of these IoT gateway devices are tasked to communicate very critical data to the cloud in real time and even minutes of downtime is not warranted

    There are a few standards that verify the durability of the gateway. One should look for certifications such as E-Mark, IP64, MIL-STD 810G, SAE J1455 etc. Moreover, if the IoT gateway is supposed to work in a hazardous environment, Class I Div II certification is essential.

    MarketWatch: AAEON’s AIOT-ILRA01, AIOT-IGWS01, ReliaGATE 20-25 are few of the gateways that are built to work under harsh environment.

    AIOT-IGWS01 Gateway

    Source: AAEON

  5. Data Pre-processing Capabilities

    6. IoT gateways are getting smarter to cater the need to process the data closer to the source. We are talking about the Edge analytics enabled IoT gateway device.

    There may be a scenario in an IoT setup where some amount of data needs to be processed as soon as the data is captured. This is possible only when an IoT gateway is equipped for it.

    For such applications, Edge Analytics-enabled IoT gateways are being widely used.

    Video surveillance, home automation, augmented reality applications, smart-city management are some of the identified use-cases of IoT gateway solutions with Edge Computing capabilities.

    Local storage is also quite crucial for IoT gateway devices in order to provide Edge analytics capabilities, as the data needs to be stored before processing.

    Depending on the amount and type of data collected, one can choose the size of the local storage. In case of video surveillance, IoT gateways supporting HDDs should be the right choice.

    MarketWatch: HPE Edgeline EL1000, Dell Edge Gateway 3001/2/3, ReliaGATE 10-12 etc. are a few of the Edge enabled IoT Gateways that offer built-in Edge Analytics.

  6. Support and Serviceability of the deployed IoT gateway devices

    7. Serviceability of the product must be ensured for uninterrupted operation of the field deployed IoT projects. IoT Gateway downtime can lead to a situation where the entire operation is interrupted. This in turn can cost very dearly to the organization.

    Most IoT gateway manufacturers provide support and service but the service response time is a very crucial factor in a gateway failure scenario. It is advisable to check with the IoT gateway vendor about this, before deployment.

  7. Firmware Update and Diagnostics

    8. An IoT Gateway device should be capable of running self-diagnosis and report error if any. It should also have provision to update the firmware in order to fix the glitches experienced during its operation in the field.

    Firmware update also aids in adding new features to the gateway even after it is deployed in the field.  Any security loop holes can also be fixed via firmware updates.

  8. Cost Factor

    9. Cost is a major factor for consideration when looking for an off-the-shelf gateway. Most gateways come equipped with multiple connectivity options along with different other features.

    You may not require many of these connectivity options and the additional features for your IoT project implementation. Also, these extra features may contribute to increased power consumption.

    Therefore, it is always good to clearly analyze the requirements prior to looking for IoT gateway solutions. You will not only be able to save the upfront cost but also save exponentially after your IoT solution is deployed.

To Sum Up…

Picking up the right gateway is quite critical for your IoT deployment. With so many variants around, things only get more perplexing.

We have tried to break it down for you to help you make more informed decisions while selecting the best suited IoT gateway solutions.

  • May 9, 2018
  • 0

Decoding the “Component Concept” of the Application Layer in AUTOSAR

Tags :

Category : Embedded Blog

As you know, the AUTOSAR or AUtomotive Open System Architecture was  developed to create a common standardized software architecture for designing automotive electronic control units (ECUs). The AUTOSAR architecture is based on a 3-layered architecture model, developed jointly by the stakeholders of the automotive industry including – the automobile manufacturers, the suppliers, and the tool developers.

The 3-Layered AUTOSAR Architecture

Let us have a quick look at the AUTOSAR software architecture. The AUTOSAR specifies a three-layer architecture, which are categorized into following modules:

  • Basic software (BSW): can be defined as standardized software module offering various services necessary to run the functional part of the upper software layer. This layer consists of the ECU specific modules along with the generic AUTOSAR modules.

    It is divided into three sub layers namely the Services layer, ECU (Electronic Control Unit) abstraction layer, and the Microcontroller Abstraction Layer (MCAL).

    The MCAL is a software module that abstracts all the upper layers ( the application layer and the BSW) Microcontroller. Thus, MCAL helps in making the upper layers independent of the low lying hardware platform.

  • Runtime environment (RTE): acts as a middleware between the AUTOSAR application layer and the lower layers. Basically, the RTE layer manages the inter- and intra-ECU communication between application layer components as well as between the BSW and the application layer.

  • Application layer: The AUTOSAR application layer includes various application specific software components that are designed to execute specific set of tasks, as per the use-case.

In this blog, we would be discussing about the AUTOSAR Application layer in detail.

1 AUTOSAR Archtecture

The 3-Layer AUTOSAR Software Architecture; Image Credit: researchgate

The Application Layer in AUTOSAR

The AUTOSAR Application layer constitutes the topmost layer within an AUTOSAR software architecture and is identified to be critical for all the vehicle applications. The AUTOSAR standard specifies the application layer implementation using a “component” concept.

While talking about the application layer implementation, three of the most important parts that should be considered are:

  • The AUTOSAR application software components
  • The AUTOSAR ports of these components
  • The AUTOSAR Port Interfaces

AUTOSAR application software components: A typical E2E(End to End) functionality includes many interconnected AUTOSAR Application Software Components (SW-C). The application software component constitutes the simplest form of an application with certain functionality. AUTOSAR defines standardized interfaces associated with all the application software components required to develop automotive applications.

These software components are connected with the help of well-defined ports. These ports facilitate communication between the software components as well as with the AUTOSAR BSW. In the context of the Application Software Components, there are certain entities called the Runnables, which are basically the  procedures that contain the actual implementation of the software components.

Runnable or Runnable Entities are defined within the VFB specifications and is part of an atomic software component (described in a later section). Runnable are defined as the smallest fragments of code or a sequence of instructions given by component and executed by RTE. A runnable entity is triggered either cyclically or during an event such as data reception.

AUTOSAR Software Component

Image: Depiction of a typical Software Component

An AUTOSAR SWC can be considered only as an atomic entity, this means that every instance of an AUTOSAR SWC is assigned to only one ECU and cannot be distributed across many ECUs.

Types of Software Components of  AUTOSAR Application Layer:

To understand the AUTOSAR software component in further detail, it is vital to look at  the various types in which AUTOSAR SW-Cs are available within the application layer

  1. Sensor/Actuator Software Component: A type of AUTOSAR Software Component for handling sensor evaluation and actuator control functions. This particular AUTOSAR Software Component depends on the associated sensor/actuator and is independent of the specific ECU, to which it is mapped to.
  2. Composite Software Component: A composite component offers a logical interconnection of other components, which could be either atomic or composite. These components are called prototypes and usually are not required to be deployed on the same ECU. Instead these can be distributed over several ECUs.
  3. Atomic Software Component: An atomic software component is the smallest form of software component that cannot be decomposed further into smaller units. And contrary to the composite type, an Atomic Software Component can be assigned to only one ECU.

The AUTOSAR ports: The AUTOSAR Software Components use well-defined ports, which encapsulate certain interfaces as a guarantee for type safety while components are communicating with each other.

A port is mapped to a single component and represents a communication point between the components.  This inter-component communication is managed by the Virtual Function Bus (VFB).

The AUTOSAR Interfaces:

As we discussed earlier, the AUTOSAR standard defines certain standardized interfaces for the application software components that are required to develop various automotive applications. This definition of the interfaces helps in obtaining the required functionality of the vehicle application.
In order to better define the communication of data or services through port of a typical component, the AUTOSAR introduced the Interface concept. The port interface required by an application software component serves as the input to the RTE port creation.  An AUTOSAR Interface is categorized into:

  1. Client-Server interface: This interface defines a set of operations that can be invoked based on the client-server pattern. Here the client initiates the communication, and requests the server to perform a service.

    The server performs the request service and sends a response to the request. The direction of the message initiation can be used to identify if the AUTOSAR Software Component is a client or a server. In the diagram below, the client the AUTOSAR SWCs, client 1 and 2 respectively , request a service through the RPorts ( Request Port) which is sent to the, the server AUTOSAR SWC which offers the required services through the PPort ( provider Port).

    AUTOSAR Communications

    Image: The client server communication between AUTOSAR software components.

  2. Sender-Receiver interface: This interface defines an asynchronous information distribution and allows for a more data-oriented information exchange over the virtual function bus.

    3. The decision related to what all information should be exchanged through sender-receiver communication and which of the services should be called by the client-server communication – are taken by the interface.

    Data Distribution

    Image: Data distribution through the sender-receiver interface type

Communication Between the Software Components ( SW-C)

During design time of an AUTOSAR application, the VFB is used to manage the communication between the software components. This virtual bus abstracts the applications from the infrastructure. VFB is an abstract component that is represented usually by the Runtime Environment (RTE) at the runtime, and generated uniquely for each ECU in the AUTOSAR system. The VFB connects the various SWCs in the design model .

The VFB communicates via dedicated ports, which means that the communication interfaces of the application software must be mapped to these ports. The VFB handles communication both within the individual ECU and between ECUs.

ECU Communication

Image: Types of communication between the SW-Cs; Image credit: techiscafe

The communications between the applications software component can be:

  • Inter-ECU. Or
  • Intra-ECU

as explained in the diagram above. Both the inter and intra-ECU communication between the application software components communication is managed through the RTE.

The interaction between ECU I and ECU II  is an example of inter-ECU communication and takes place through and beneath the RTE  and goes via the Basic Software Module. The BSW handles the functions like  interactions with the memory, diagnostics,  along with communication services ( if needed) for the inter-ECU communication.

The intra-ECU communication, that is the communication within the ECU between the software component B ( SW-C B) and the software component C (SW-C C ) , is entirely through the RTE.As evident from the diagram , the software components that are mapped to a single ECU use the Intra-ECU method.

The Role of RTE: The implementation of the AUTOSAR software components is made independent of available communication mechanisms by the RTE by offering a uniform environment to these to AUTOSAR Software Components ( SWC).

Application layer exchanges data with the underlying layers via the sender and receiver ports of the RTE. Whenever an AUTOSAR software component calls for the service objects, the RTE maps these requests to the actual service object symbols on the local ECU.

The Complex Device Driver Exception – offering direct access to hardware

As the layered nature of the AUTOSAR software architecture does not allow direct access of the hardware by the upper layers, an additional concept was needed to bypass this restriction especially for the resource critical and/or Non-AUTOSAR compliant software components.

And it is here that the Complex Device Driver comes into scenario. The Complex Device Driver basically offers an AUTOSAR Interface to the application layer and thus gains direct access to values on the physical layer.

The concept of Complex driver is useful for application components that call for a direct access to the hardware devices on the ECU. Injection control or electronic valve control applications are good examples of such applications that require direct access to the hardware.

If we look at the AUTOSAR application layer implementation process, it is a function of the AUTOSAR Software Component which is independent of:

  1. The type of Microcontroller of the ECU being mapped.

  2. Type of ECU being mapped

  3. The location of the AUTOSAR Software Component

  4. The number of times a software component is instantiated within the system or an ECU.

The application software implementation within the AUTOSAR is encapsulated within the software components and forms the core of the AUTOSAR application implementation process.

  • May 7, 2018
  • 0

Decoding the Implementation of UDS Vehicle Diagnostics in AUTOSAR Base Software Module

Tags :

Category : Embedded Blog

For all the automotive technology enthusiasts, AUTOSAR needs no introduction. The AUTOSAR consortium was formed by the automotive OEMs to counter the complexities created due to increase in the use of ECUs (Electronic Control Units) in the automobiles.

This AUTOSAR software Architecture ensured the decoupling of product functionalities from the hardware and software services.

This standardization has helped the automotive embedded developers in focusing primarily on the innovations in the product feature development rather than working on different architectures.

This shift in automotive ECU development approach has proved to be equally beneficial for the automotive OEMs and their Tier-1 suppliers. Why, you ask? Post-AUTOSAR, OEMs’ and Tier-I Suppliers have been able to save costs spent on different software development tools required in era of non-standard architecture.

AUTOSAR software architecture has brought about a standardization that the OEMs and suppliers follow to develop software without facing any compatibility issues.

When Vehicle Diagnostics Met AUTOSAR Software Architecture

In automotive, diagnostics is required to be performed on all ECUs to ensure there is no issue with any electronically controlled component of the vehicle. Any issue encountered by the automotive ECU is stored as Diagnostics Trouble Code (DTC) in the Electrically Erasable Programmable Read-Only Memory (EEPROM). These codes can be retrieved later using an automotive diagnostic tool.

Now the vehicle diagnostics system needs to be implemented in the AUTOSAR architecture and this is what this blog aims to explore.

To understand how the diagnostics is implemented in AUTOSAR architecture, let us quickly revisit the architecture.

In the base software layer, there are hundreds of software modules including those categorized under the Microcontroller Abstraction Layer (MCAL), ECU Abstraction Layers and Service layer.

The blog will focus on the service layer of the AUTOSAR Base Software Module as the vehicle diagnostics services are stored here.

There are essentially three modules inside this layer tasked with different responsibility with respect to vehicle diagnostics. We will discuss them in the subsequent sections.

In the diagram below, the different components of the diagnostic stack(DCM, DEM, FIM etc.) can be seen.


AUTOSAR DIAGNOSTIC STACK
Source: Mathworks

  1. Diagnostics Communication Manager (DCM)

    The diagnostic communication manager (DCM) has the responsibility of reading and writing the fault codes or diagnostic trouble code in the fault memory of the automotive ECU. It supports the implementation of the diagnostic protocols such as UDS (ISO 14229) and OBD II.

    When an automotive ECU receives a diagnostics request from the tester tool, the DCM preprocesses it. While it handles majority of the requests, any other request is routed to the functional software. Every new version of DCM has an enhanced functional range which increases its ability to handle diverse types of diagnostic requests

    DCM comprises of the service identifiers (SID), data identifiers (DID) sub-functions and routine identifiers to handle the vehicle diagnostics requests.

    While handling the diagnostics requests from external testing tools during ECU software development, vehicle program production or garage servicing, the DCM also manages the session and security states.

    For instance, the DCM checks whether a particular diagnostic request can be supported and also if the execution of that service will be carried out in the current session.

    We will delve little deeper into the different components of DCM and how they interact with each other.

    Diagnostic Session Layer: This sub-module is tasked with ensuring the flow of data related to the diagnostic requests and the responses. Diagnostic session and security states are managed by this layer along with the supervision of timing parameters of the diagnostic protocol.

    Diagnostic Service Dispatcher: The validity of the incoming diagnostic requests needs to be checked and this is where this sub-module comes into the picture. In addition to ensuring the validity of the request, it also keeps track of the progress of the request.

    After the validation is done, this sub-module processes a stream of diagnostic data and also transmits the response post data processing.

    Diagnostic Service Processing (DSP) Module: This is the place where the real processing happens. DSP analyzes the format of the service request and interacts with other components of the AUTOSAR BSW to fetch the data required for the processing. The service response is also assembled by it.

    These three sub-modules interact with each other with the help of defined interfaces. Describing these interfaces is beyond the scope of the blog and we will discuss them in detail in the subsequent blogs.

    In order to make the automotive ECU an AUTOSAR compliant product, DCM needs to be first configured using tools like Vector Tool Chain. During the development process, all the necessary APIs are coded in the DCM including the general DCM definitions.

    Unit testing and integration testing follows the development process. Unit testing is performed using tools like Tessy Test Systems where the source module is analyzed and the functions are tested.

    Integration test is performed on the evaluation board where the data exchanged between the modules is verified. Basically, it tests if all the interfaces are functioning without any issue.

  2. Diagnostics Event Manager (DEM)

    DEM is responsible for storing and processing diagnostic errors (events) and all the data associated with it. In addition to it, DEM provides the diagnostic trouble codes (DTC) to the Diagnostic Communication Manager (DCM) as and when required.

    Providing the interface to the application layer of the ECU and to other modules of the AUTOSAR Base Software Module is also one of the responsibilities of DEM.

    There can be two type of event that can be reported to DEM:

    • Base Software Event- Event reported by the base software
    • Software Component Event reported by the AUTOSAR application layer

    The events reported to the DEM need to be first qualified to ensure that whether it is a fault (failure of a component) or just an occurrence (irregular system behavior).

    After the event is qualified, DEM records the event data and communicates with DCM for event handling and FIM (Function Inhibition Module) for functional control (Described in next section).

  3. Function Inhibition Module (FIM):

    FIM is essentially the control mechanism for AUTOSAR Base Software and software components. The FIM has to control the functionality available to these components depending on their inhibit conditions.

    An identifier is assigned to the functionalities with an inhibit condition. Only in the scenario of inhibit condition being not true, the functionality is executed.

    The role of FIM is to configure and modify the inhibiting conditions of the functionalities. By doing so, a particular functionality can be adapted easily to a new system context.

    FIM services are primarily focused on the applications residing in the software components; however, the AUTOSAR Base Software (BSW) can also use the services of FIM when required.

    The FIM has a close connection with DEM as the diagnostic events and their status info are considered as inhibit function by the FIM. When a failure is detected, it is reported to the DEM and it is the job of FIM to stop the particular functionality.

Conclusion

The implementation of UDS in the Base Software of AUTOSAR architecture requires two states of designing and highly complex coding during the configuration.

Moreover, the configuration of the Diagnostic Communication Manager (DCM) needs to be done with respect to certain parameters defined by AUTOSAR. This is where AUTOSAR Tool Chains become very important.

These platforms help the developers’ auto-generate certain code and write the rest. Configuration of the parameters also becomes quite easy with the tool chain programs like Electrobit, Vector Tool Chain and a few others.

Archives

Contact Us

© 2018 Embitel. All Rights Reserved