9th March 2020
by

Understanding How the Microsoft Cloud Solution Provider (CSP) Program Can Help You Optimize Costs

Many small and midsize organizations are under constant pressure to reduce their IT and operations costs while not compromising their quality and services. Software Licenses form an important component of a technology budget and are often associated with a significant cost. Now, with the Microsoft Cloud Solution Provider (CSP) program, an organization can save significant cost on their Cloud Licenses every month. The CSP Program is a 3-4 years old program that was designed by Microsoft for partners to help their customers with cloud licenses and provide value-add services. The CSP program offers discounts on all Cloud Licenses – Office 365, Microsoft 365, Power BI, Dynamics 365, Project, Visio, Flow, PowerApps, Enterprise Mobility, Windows 10, Azure Subscriptions and more.

The CSP program offers more flexibility as compared to other Microsoft licensing models. Below are some of the benefits of CSP compared to other program models:

  • Better discount on licenses as compared to the pay-as-you-go model and different Volume Licensing models.
  • CSP offers monthly and annual billing options and requires no upfront expenses compared to other models that offer only yearly billing options and require payment at the time of service.
  • There is no minimum for license purchases with CSP allowing you to tailor solutions to fit your business with as little as one license.
  • With CSP, you can add/remove licenses anytime and adjust your payment model accordingly. Other model options like EA, Volume Licensing only allow a change in users at the end of a cycle, resulting in payments for services not always fully utilized.
  • CSP engagement includes comprehensive license support automatically.

As a Direct CSP Partner (Tier 1), iLink offers Cloud Licenses to customers at discounted prices and help them save significant cost every month. If you are evaluating different licensing models or looking to save costs, iLink has solutions to fit your business.

To learn more about how we can help you save Cloud Licenses cost talk to an expert now.

MDF Funds
6th March 2020
by

What are MDF and Co-op Marketing Funds and How Are They Different?

According to channel industry observer CRN, trends show channel partners reducing the average number of vendors they work with from 18 to 14. IT vendors are therefore faced with more challenges when recruiting channel partners. In order to better attract prospective channel partners, IT vendors must include financial incentives like MDF (Market Development Funds) or co-op marketing funds in their channel partner programs to entice MSPs, VARs, and other channel partners to select them over their competitors. This post defines these financial incentives and their differences. 

It is quite common for the terms MDF and co-op marketing used interchangeably, but to do so is actually inaccurate, as they are acquired by channel partners in different ways and at different times. The key difference between MDF and co-op marketing funds is that a vendor will offer MDF funds to channel partners before any sale has taken place (usually as part of a marketing program with defined criteria) whereas co-op funds are given after sales have taken place. For example, MDF funds are commonly provided to a select group of channel partners to kick-start and/or accelerate sales, deployments, or consumption of products or services by their customer base. Co-op funds, on the other hand, are given to channel partners who have already sold a vendor’s product to encourage them to further market and sell more of that vendor’s offering. 

Market Development Funds (MDF) 

MDF are funds held by vendors and offered to select partners based on the specific needs of the vendor and the potential for success of the partner. A vendor wishing to increase sales, deployments, or consumption for a specific product/service or looking to penetrate a new vertical market may grant MDF to a partner who has proven their expertise or sales prowess or has access to a strategic customer. MDF is given at the vendor’s discretion to select channel partners prior to any sales taking place and the amount can vary from partner to partner. Specific sales and marketing plans as well as ROI are discussed before the funds are given, and the partner must provide the vendor with detailed reporting of outcomes. 

Co-op Marketing Funds  

Co-op marketing funds are accrued as a percentage of prior sales. Vendors who provide co-op marketing funds usually make them available to most, if not all channel partners, but the percentage of money received may increase or decrease based on sales from their VARs, MSPs or other solution providers. The vendor or manufacturer often implements rules on how the funds can be used and pre-approval must be received prior to conducting any marketing programs. However, once the funds are received by the partner, they are then owned by the partner and cannot be taken away. 

MDF or Co-Op Marketing Funds? 

Whether to provide MDF vs co-op marketing funds to your channel partners does not have to be an either/or decision. Some vendors and manufacturers do offer both. You can select a small group of channel partners with the largest sales potential to receive MDF funds and then they, as well as a larger group of channel partners, will receive co-op funds as a percentage of future sales.

IoT Cloud Platforms
5th March 2020
by

IoT Cloud Platforms: Foundations and Architectural Patterns

Introduction – Understanding the Challenges

Manageability of Distributed Devices at a Massive Scale

Real-world IoT solutions often have a large fleet of devices deployed across a geographically distributed area. These devices can be heterogenous in nature – supplied by different manufacturers, of varying hardware specifications, and with varying feature-capabilities. Moreover, field-devices often have poor or intermittent connectivity to backbone networks.

This brings-up a critical need to reliably interconnect devices over underlying unreliable networks. The massive scale and heterogeneity also bring unique challenges in the effective manageability of devices. Remote administration and servicing in the field quickly become an expensive and painstaking proposition for the operator.

Moreover, gathering massive amounts of data securely from remote devices to derive real business insights can be cumbersome – making it harder to justify the ROI on your IoT investments. IoT Cloud platforms help address these challenges.

IoT Cloud Platforms

Offering Interconnectivity, Visibility, and Remote Management

Major cloud providers today offer IoT Platforms. These platforms enable interconnectivity across heterogeneous devices to provide real-time visibility of your fleet, remote monitoring, and remote manageability – at scale! This approach also brings elasticity, so you only pay-per-use and avoid fixed and upfront capital expenditure on your computing infrastructure.

In this article we explore the common architectural patterns and foundational concepts in IoT Cloud platforms. We help understand the key considerations in building a mature architecture for your next IoT project and to make a well-informed assessment before choosing a suitable IoT Cloud Provider. Let’s dive right in.

Asset Registry

An Inventory of Managed Devices

IoT Cloud platforms offer an asset registry. This is a master inventory of all your deployed devices. The registry is essentially a cloud-database which tracks a unique ID for each device and records additional attributes about it. The asset registry thus becomes a starting point for you to list, search, monitor, and manage your devices. Commonly tracked attributes can include:

· Device ID or serial number

· Client certificate unique to each device

· Device type, model, manufacturer information

· Version of the installed OS and firmware

· List of device capabilities (CPU Type, Available IO Ports etc.)

· Device location

· Date of device onboarding, firmware update

As a solution developer, you could also include additional attributes in the device registry as you see fit for your business requirements. Device information is added to the registry manually by the operator (during solution deployments). This can be done one device at-a-time, or by importing information in bulk. Alternately, devices can self-enroll into the registry when the device is first powered-up in the field. This process is called just in time enrollment.

Establishing Device Identity and Authentication

Using Client Certificates to Securely Identify Devices To The Cloud

How does the cloud platform really know who the request is coming from or whether to trust the request from an IoT device? Could it be an impostor or a malicious source faking that request?

A simple approach could be to have a ‘shared secret’ (password) between your devices and the cloud. The device presents this ‘shared secret’ to the cloud to authenticate and then receives a session token in return. Cryptographically, this is considered quite insecure as the shared secret can be eavesdropped by a man-in-the-middle attack.

A more reliable approach is to rely on public-key cryptography. Every device is allocated a unique client certificate. The device presents this certificate to the cloud to establish its identity. Here is how it works:

Before the device is provisioned in the field:

1. A public and private key-pair is generated which is unique to this device.

2. A Certificate Signing Request (CSR) is generated for each device based on this key-pair.

3. Most IoT Cloud Platforms have a Certificate Authority (CA) which is capable of issuing digital certificates.

4. The CSR is submitted to this CA for signing.

5. Based on this CSR, the CA issues a digital certificate (X.509 Certificate) for that device.

6. The private key and the digital certificate are then installed (burned) on the device. The private key is expected to be kept secure. The public key and the digital certificate can be, of course, publicly known.

7. The Cloud Platform stores the device certificate in the device registry for future reference. Note: The Cloud does not know or store the device’s private key hereafter.

After the device is provisioned in the field and comes online:

1. Device attempts to connect with the cloud platform.

2. The cloud asks the device to present its device certificate. Device sends the device certificate to the cloud and the cloud verifies the validity of the same.

3. Cloud then send a challenge (text) to the device to prove that the device is indeed the bearer of the claimed private key.

4. Device encrypts the challenge (text) using its private key and sends the cipher-text back to the cloud.

5. Cloud decrypts the cipher-text using the public key of the device to ascertain that the device is indeed the owner of the private key.

6. Cloud now completes establishing a secure HTTPS / TLS session with the device.

7. These steps are followed every time a device attempts to connect with the cloud.

Device Groupings

Easing Manageability of the Fleet

Managing devices one at a time can be cumbersome. Here is where groups come in. Cloud platforms allow you to group devices based on their identity or specific device properties. For example, you can group all temperature sensors having a specific ARM CPU having a specific firmware version.

You can then issue commands, modify the configuration, or issue a firmware updates to that entire group of devices at once. Such group operations make manageability easy.

Groups can be statically defined (i.e. devices with specific inherent device properties grouped together), or they can be dynamically defined (based on the current ‘state’ or dynamic values of specific variables in the devices).

Pub-Sub Communication Model

A Decoupled Architecture for D2D and D2C Communication

There is a need for a robust Device-to-Device (D2D) and Device-to-Cloud (D2C) communications. The network topology can be quite dynamic, with devices and sensors intermittently connecting and disconnecting from time to time.

Traditional protocols such as HTTP are request-response centric and are designed for point-to-point communications where both sender and recipient are expected to be present at the same time (i.e. temporal coupling). Such protocols are often unsuitable for IoT needs.

Publish-Subscribe offers an alternate and resilient communications model for distributed networks. Here, all devices first connect to an intermediate messaging broker.

Figure 1: An Illustration of the Pub-Sub Communications Model

Certain devices (say, sensors) can publish messages to topics in the broker and certain other devices (say, alarms) can subscribe to those topics. Messages can contain telemetry information and each message specifies one topic it belongs to.

The primary function of the broker is to route all inbound messages destined for a specific topic to all subscribers of that topic. The broker is thus a store-and-forward engine which can ‘fan out’ incoming messages to multiple recipients depending on the interests of those recipients.

The senders and receivers do not directly know about each other’s presence and availability – thus providing a greater degree of temporal de-coupling compared to point-to-point communications.

If a device goes offline (after subscribing to a topic), the broker can also queue messages for that device. The broker will deliver these queued messages to that device when the device reconnects again in the future. This provides a powerful model for asynchronous communications.

All D2D and D2C chatter flows thru the broker and the Pub-Sub mechanism and the messaging broker form the communications backbone of most IoT Platforms today. MQTT is one such protocol specification that adopts the publish-subscribe communication model.

Device Policies

What is a Device Permitted to Do?

Can a device publish messages to any topic? Subscribe to any topic? In case a device’s security is breached, can we limit the collateral damage to the system from that device? This is where device policies and authorization controls come into the picture.

A policy is a set of rules associated with each device (specifically, the policy is associated with the device’s certificate). Policies can whitelist or blacklist what a specific device can really do at runtime. For example:

· Which topics are permitted to subscribe and publish to.

· What operations to perform on the device shadow (see later).

· What operations to perform with ongoing jobs (see later).

Once deployed, the messaging broker and the IoT Platform will enforce these policies at runtime. Messages will be routed (or blocked) in adherence to the policy. The policy can be applied to individual devices or, usually, to a group of devices.

Rules Engine

Triggering Actions Based on Events and Conditions

What do we really do with all the inbound telemetry messages? Route them somewhere? Perform specific actions based on what’s inside that message? Process, modify, and resend the modified message to someone else? The rules-engine provides these capabilities.

The rules engine is fed with a set of rules as part of its configuration and all the inbound messages are fed into this rules-engine for processing in near-real-time. Each rule consists of:

· Rule name – Human readable name of the rule.

· Matching criteria – Does the input message match this criterion? If so, trigger the Action.

· Action – Specifies what should be really done if the message matches the criteria.

Figure 2: Rules Engine

A wide range of actions can be performed when a specific rule gets triggered:

· Forward the message to another topic.

· Store the message to a cloud database.

· Write the message to a flat-file or log.

· Invoke application logic (function) and pass along the message as input to that function.

· Add the message to a specific queue for further processing.

· Update the state of a “state machine” in the cloud.

You could of course write an entirely custom logic to process every inbound message (without really needing a rules-engine). However, the rules-engine provides a structured and elegant

framework to handle all your inbound messages. Moreover, these engines are designed to massively scale to handle millions of messages every day.

Stream Processing

Real-time Processing Of Data-In-Motion

While the rules-engine is a good way to process messages in real-time, they are often constrained in their expressive capability. An alternate class of engines are available today which are better suited to real-time stream processing.

Here, ‘stream’ refers to the slew of telemetry messages sent to the IoT cloud from thousands of field devices. You specify your processing logic as a series of processing nodes connected together as a Directed Acyclic Graph (DAG).

Figure 3: Stream Processing Workflow

Every message flows-thru the pathways of the DAG and at each step a specific processing logic operates on that message. The nodes in the DAG can perform operations such as:

· Message transformation

· Aggregation and windowing

· Conditional routing of the message within the DAG

· Logging the message

Stream processing thus offers a greater flexibility and customizability compared to a rules-engine. Unlike traditional means of processing data ‘at rest’ (Ex. Databases, Data-warehouses, Filesystems), stream processing is optimized to process data-in-motion.

Protocol Gateway

Supporting Heterogenous Protocols with Protocol Translation

In an IoT solution, devices from different suppliers can use different protocols – MQTT, AMQP, HTTP, XMPP, CoAP etc. Some IoT Cloud Platforms, on the other hand, may have a specific default / native protocol that it supports – say MQTT only.

To interconnect these devices into a singular solution, IoT Cloud Platforms offer a gateway which provides protocol adaptation. The gateway translates messages from one format to another in real-time and providing full bi-directional support, thus addressing the ‘impedance mismatch’ problems between protocols.

Here are some functions that the gateway can perform:

· Message transformations

· Message compression / decompression

· Message encryption / decryption

· Custom authentication

The protocol gateway is often an optional component to be used only if devices are incompatible. These gateways are often extensible, so you can integrate your proprietary or custom protocols onto it as well.

Device Shadows

A Virtual Clone of Your Device In The Cloud

Consider the scenarios below:

1) Your application would like to read the state of a specific IoT device – say, to display this information to the user.

2) Your application would like to modify the state of a specific IoT device – say, to control an actuator connected to that device.

The application would like to do so with minimal latency and without having to ‘busy wait’ for the device (as the device connectivity may be intermittent) or without waiting for a slow round-trip to the device. This is where device shadows can help.

A device shadow represents a virtual representation of the device in the cloud. It is an object (stored in the cloud DB) which represents the ‘last reported state’ of the device. The device periodically sends its own state information to keep the device shadow up-to-date. Applications can read from the device shadow instantly, without waiting for a round-trip to the actual device.

When the application wishes to modify the state of a device (say flip a flag to turn-on the light), it can directly modify the ‘desired state’ object in the device shadow. This becomes a fire-and-forget operation for the application’s point of view. When the device connects to the cloud platform the next time, it can read the ‘desired state’ from the device shadow and invoke its actuators to try and reach that desired state.

This offers a convenient decoupling to build your web and mobile applications which only have to interact with the device shadow (without having to deal with the actual device itself). It simplifies the programming model of those applications as they no longer have to deal with device-specific protocols or to busy-wait for device availability. Fire-and-forget!

Summary

Thus far, we have explored the foundational concepts and capabilities of IoT Cloud Platforms. The design patterns discussed here help build a robust and secure architecture for your IoT solutions. To recap, the patterns:

· Asset Registry

· Client Certificates

· Device Grouping

· Pub-Sub Communications Model

· Device Policies

· Rules Engine

· Stream Processing

· Device Shadow

Solution integrators today have a lot of Cloud Platform options to choose from. This is a constantly evolving and innovating space. We recommend doing a thorough assessment of the platform capabilities using the parameters discussed here before choosing a specific IoT platform for your next project.

6 Critical Themes in using Empathy to Understand Customers
5th March 2020
by

6 Critical Themes in using Empathy to Understand Customers

In cultivating a product into fruition, Product Managers extoll the value of empathy as a key component to success. But what should we listen for? What questions should we ask? Sometimes there are too many problems to solve in too short a time. How do we decide what to work on first? Like any good PM problem, let’s break a complex problem down using a framework:

The Customer Journey

Through the lens of Empathy, we can look at each stage of the customer journey and dive into a set of key questions that help us distill product strategy, tactics, and prioritization. If we can answer these, we are much closer to truly meeting our customers where they are. To start, let’s use a common set of customer stages that align well whether we are delivering a B2B or B2C product:

Screenshot (50)

What are some good questions to drive empathy at each stage? Let’s get started!

Awareness: Getting them to look at us.

Empathy Questions

Timing – When is our audience intended to see our product? Are they scrolling through Facebook? Looking at eEmail? It’s generally best to capture someone at the moment they are most open to thinking about new ideas. Do we want our audience to find us when they are looking for distractions or when they are focused on getting things done?

Relevance – What are some of the daily pain points of our target personas? Are we calling out directly to those pain points?

Remarkability – Awareness is also a function of the “elevator pitch” of our vision and product. How remarkable are we? Pick an extremely targeted audience, but let’s shape our pitch to them really well. Are we capturing a pitch that is unique, safe, reliable, and relevant?

Acquisition: An invitation to delight.

Empathy Questions

Presentation – Presentation is sometimes everything. Now that we have their attention, do we know how to surprise and delight our target audience? Do we know how to strike that balance between overwhelming them or seeming insincere about our value proposition?

Story – How well are we answering the needs/pains of our customers? When should we focus more on the features we provide, versus the customer pains we solve? How quickly can someone get a complete understanding of our product’s value proposition?

Decision – The customer wants to sign up! Can they see how to do that? Is our sign-up process as well-crafted as our overall presentation?

Activation: They’re convinced. How’s our hospitality?

Empathy Questions

Clarity – How confident is a customer when they sign up with us? Do they have a clear idea of what they’re signing up for? How does our sign-up flow respond to the type of customer they are?

Education – When a potential customer decides to sign up with our product, they are ready for us to teach them. How “experienced” do they need to be to learn how to use our product? Graduate degree level? Elementary school level? What language does our audience understand?

Speed – Activating a new customer is a balance between speed and care. Sometimes we need to allow for users who learn by doing instead of following. How fast can our customers get to the core features/value from the moment they click “sign up”? How much do they have to read? How much do they have to watch?

Revenue: Their money is in our hands. Don’t stop now.

Empathy Questions

Cost – How do customers feel about the amount of money they spent? Did they invest heavily and are depending on our product to deliver? Or did they toss money at an interesting novelty?

Return on Investment – How soon can a customer see value from the moment they invest in our product? Do they require some time to spin up, or can they start fulfilling on their goals right away? How do they feel about the learning curve?

Management – How easily can a customer manage their relationship with us? How much control can we give them without increasing their workload? How many hurdles do they have to jump to keep their information fresh and up-to-date with us?

Retention: Are we considered a must-have?

Empathy Questions

Care – Now that an opportunity has converted into a true customer, how do we care for them? How do we respond when they have trouble? Can they expect to get help when they are most likely to be using our product?

Decision-making – The fewer decisions we force our customers to make, the less burden we place on them to succeed. How many decisions do we require a user to make for each use case? How can we lower that number?

Enthusiasm – Does our customer love us? Congratulations! How do we allow them to show it? Do we offer them content to read? Feedback loops with engaged support staff? Direct communication with key personnel?

Referral: Do we allow them to love us?

Empathy Questions

Message – What would we want our customers to say about us to other people? Do we know how they talk about us? How easy is it to describe what our product does?

Ease – Getting a customer to refer us to someone else is typically outside of the core value proposition for a customer. How much do they actually love us? Do we make it easy for them or hard to share with their friends/colleagues?

Timing – When would a customer be most enthusiastic to share about us? While they are using the product? Perhaps another time? How do we tee up their enthusiasm into a desire to share?

Use these questions to cultivate a better understanding of the experience of our customers, and prioritize accordingly. As owners of a product, we can always expect to do a bit of guesswork, but the more completely we can answer these types of questions, the better chance we have of building a long-term sustainable product business.

21st February 2020
by

Application Modernization & Microservices

In today’s era of digital transformation application modernization is one of the key strategies towards the path of digital transformation. So, what does it means by application modernization, is it to change the look and feel of the application or move it to cloud or migrate to software product or service and get rid of legacy application? Or maybe all of it? And answers to these questions will vary but in general application modernization means to preserve the business value of the application at the same time make it agile in nature to update/upgrade to meet constantly changing demands of market. And Cloud being de facto platform for modern applications, migration to the cloud is one of the to way achieve the agility for an application.

Let’s look at high level various approaches to migrate applications to cloud available that enterprises are adopting based on their cloud adoption maturity. At the same time, it should be noted that enterprise cloud maturity is not the only deciding factor for choosing the migration strategy for application.

Fig. a Cloud Maturity vs. Application Migration Strategy

Before we discuss in detail about Microservices as rearchitecting approach of application modernization lets quickly understand each migration strategy.

Rehost: Often referred to as a “lift-and-shift” migration. This option doesn’t require code changes, and lets you migrate your existing apps to cloud rapidly.

Refactor: Often referred to as “repackaging,” refactoring requires minimal changes to apps and specifically to application configuration, so that it can deployed on PaaS or Containers. This approach is also known as Replatform.

Rearchitect: Rearchitecting for migration focuses on modifying and extending app functionality and the code base to optimize the app architecture for cloud such that it can take maximum benefits of cloud services to achieve scalability, flexibility and resiliency.

Rebuild: Rebuild takes things a step further by rebuilding an app from scratch leveraging cloud native technologies like serverless functions, cognitive services, database etc.

Microservices

As mentioned above microservices are application re-architecting approach to cloud migration. In other words, it is an architectural approach to divide monolithic application into small services or micro services. Please note the word micro does not imply the size of the service in terms of line of code or number of functions. It defines the subset of functionality decoupled from rest application modules or services.

How microservices are different than monolithic application?

  1. A monolithic application contains domain-specific functionality and is normally divided into functional layers like web, business, and data.
  2. You scale a monolithic application by cloning it on multiple servers/virtual machines/containers.
  3. A microservice application separates functionality into separate smaller services.
  4. The microservices approach scales out by deploying each service independently, creating instances of these services across servers/virtual machines/containers.

Following are the key characteristics of the microservices which helps us further understand how we should design the microservices as we split the monolithic application.

Small and Business Focused: Microservices should be built to serve specific business function. For example, an ecommerce application can have different microservices called catalog service, payment service, order processing services etc. aligned to business component of application.

Loosely Coupled: Microservices should be independent of each other such that it can be deployed and scaled rapidly and frequently.

Defined End Points: Microservices should have standard endpoint for all its consumer through which it communicates to its consumer and vice versa.

Black Boxed or Self-Contained: Microservices underlying details of their complexity, dependency and implementation should be independent of each other.

Polyglot: Microservices are polyglot in nature, each microservice can be developed and run on its own set of technology.

With all these characteristics of microservices stated above below are key advantages of microservices over monolithic application:

  • Overcome performance issues by design.
  • Allows flexibility in scaling specific business component or function.
  • Avoids longer cycles for regression testing as features can be developed independently.
  • Overcome unscheduled downtime of entire system due to bottlenecks.
  • Allows rolling updates and makes problem identification and debugging easier.
  • Flexible to adopt right suitable technology and programming language.
  • Divides big teams into smaller teams working independently.
  • Reduces dependency and help improve productivity among development teams.

At the same time all these benefits do not comes free and microservices has certain cons that we should consider while deciding adoption of microservices approach. Following are some of these drawbacks of microservices:

  • Increased complexity in communication between different services.
  • Eventual consistency and state management across services.
  • Increase in resource utilization and management.
  • More technology and relevant skills to maintain.
  • Testing and deployment complexity increases.

In order to decide whether microservices architecture is right approach for your application or not right evaluation of its pros and cons should be done specific to business application and here at iLink we help our customers to make right decision by providing right justification to recommended approach.

Industrial Protocols
14th February 2020
by

Making Sense of Industrial Protocols

Overview

Why Modbus?

We received this question from a student at a recent IIoT Learning Class. We found it particularly prescient given the latest discussions going on around Industry 4.0. The question is technically sound and indicates a thorough understanding of the technology’s functionality—but perhaps not its purpose.

The answer, however, is much deeper, and accounts for what lies ahead in terms of industrial Protocols.

What is Modbus protocol?

Modbus Protocol is a messaging structure developed by Modicon in 1979. It is used to establish master-slave/client-server communication between intelligent devices. It is a de facto standard, truly open and the most widely used network protocol in the industrial manufacturing environment. It has been implemented by hundreds of vendors on thousands of different devices to transfer discrete/analog I/O and register data between control devices. It’s a lingua franca or common denominator between different manufacturers. One report called it the “de facto standard in multi-vendor integration”. Industry analysts have reported over 7 million Modbus nodes in North America and Europe alone.[/vc_column_text]

Where Modbus is used?

Modbus is used in multiple master-slave applications to monitor and program devices; to communicate between intelligent devices, sensors and instruments; to monitor field devices using PCs and HMIs. Modbus is also an ideal protocol for RTU applications, where wireless communication is required. For this reason, it is used in innumerable gas and oil and substation applications. But Modbus is not only an industrial protocol. Building, infrastructure, transportation and energy applications also make use of its benefits.

The right tool for the right task

When it comes to choosing a network for your device, Modbus TCP/IP offers several significant advantages:

  • Simplicity: Modbus TCP/IP simply takes the Modbus instruction set and wraps TCP/IP around it. If you already have a Modbus driver and you understand Ethernet and TCP/IP sockets, you can have a driver up and running and talking to a PC in a few hours. Development costs are exceptionally low. Minimum hardware is required, and development is easy under any operating system.
  • Standard Ethernet:There are no exotic chipsets required and you can use standard PC Ethernet cards to talk to your newly implemented device. As the cost of Ethernet falls, you benefit from the price reduction of the hardware, and as the performance improves from 10 to 100 Mb and soon to 1 Gb, your technology moves with it, protecting your investment. You are no longer tied to one vendor for support, but benefit from the thousands of developers out there who are making Ethernet and the Internet the networking tools of the future. This effort has been complemented opportunely with the assignment of the well-known Ethernet port 502 for the Modbus TCP/IP protocol.
  • Open: The Modbus protocol was transferred from Schneider Electric to the Modbus Organization in April 2004, signalling a commitment to openness. The specification is available free of charge for download, and there are no subsequent licensing fees required for using Modbus or Modbus TCP/IP protocols. Additional sample code, implementation examples, and diagnostics are available on the Modbus TCP toolkit, a free benefit to Modbus Organization members and available for purchase by non-members
  • Availability of many devices: Interoperability among different vendors’ devices and compatibility with a large installed base of Modbus-compatible devices makes Modbus an excellent choice.
    Open Chat

    Etiam magna arcu, ullamcorper ut pulvinar et, ornare sit amet ligula. Aliquam vitae bibendum lorem. Cras id dui lectus. Pellentesque nec felis tristique urna lacinia sollicitudin ac ac ex. Maecenas mattis faucibus condimentum. Curabitur imperdiet felis at est posuere bibendum. Sed quis nulla tellus.

    ADDRESS

    63739 street lorem ipsum City, Country

    PHONE

    +12 (0) 345 678 9

    EMAIL

    info@company.com

    PURCHASE