Calling all CFOs: Why connecting with a toothbrush might just be worth it

Until recently, technology vendors and the companies that buy their wares have focused largely on what the technology does – what features it has, the capabilities it can offer. But it’s no longer about what technology can do, it’s about what it can enable, says Tony Kontzer, a business and technology writer.

The fact that a manufacturer can communicate with a toothbrush may represent technological wizardry. However, it’s the knowledge the company can collect from the resulting data stream — such as how many brushings a customer can get out of a single toothbrush — that brings real value.

Looking through the digital transformation lens

Too often, technology buyers have looked to impress with bells and whistles, when what’s really needed are positive financial outcomes. The act of undergoing digital transformation now takes on a completely different context.

We don’t transform so that we can add technological capabilities, we transform so we can become more agile and more efficient. We transform to create better customer experiences, which can lead to increased profitability. We transform to make our businesses stronger, not just to create a splashier IT narrative. All technology investments today should be viewed through this lens.

Enterprise technology vendors should not be in business simply to make great technology, but should help customers tap into the latest technologies to take their businesses to another level. They need to understand that no matter how cool the products and solutions are, if they’re not making an economic contribution that helps an organisation achieve a vision or meet its mission, then the company might as well carry on making cat food in the same way that it always did.

CFOs pivotal in making digital transformation transform the business

This is why ALE, a global communications technology vendor, has increased its effort to speak directly to CFOs. Often tasked with overseeing IT organisations to ensure that technology investments bring real bottom-line value, CFOs are unimpressed with the coolness factor. They are skeptics who look past the hype and go straight to the value a technology can deliver. No value, no purchase.

It is for this reason that CFOs have become integral to the process of digital transformation. It is all too easy for a company looking to inject digital capabilities into its operations to do so merely based on those capabilities themselves. Oooh, look, we can move our infrastructure assets to the cloud and cut our CapEx costs! We can extend our customer-facing processes to mobile platforms! We can invest in IoT sensors for all of our warehouses and keep a closer eye on our products!

Tony Kontzer

While all of these moves may make perfect economic sense, companies frequently jump into them before they’ve properly analysed the impact they will deliver. They fail to determine whether a particular technology, regardless how impressive it is, is the right match for their transformation effort.

And if customers make ill-advised investments in the technologies offered and discover too late that the payoff isn’t there, everyone loses. The customer spends money unnecessarily and ends up with […]

The post Calling all CFOs: Why connecting with a toothbrush might just be worth it appeared first on IoT Now – How to run an IoT enabled business.

Blogs – IoT Now – How to run an IoT enabled business

Connecting hardware and software lifecycles to build the Internet of Things

Traditional software development practices and tools can’t scale up to support the accelerated delivery cycles and iterations of products designed for the Internet of Things. You need modern tools and practices designed for the IoT to succeed.

In the past, traditional development methodologies were waterfall and led in one direction: from design to deployment, with little data coming back to the development team from deployed products. However, in the Internet of Things, embedded software and sensors in the hardware send operational data back for analysis and action back to the developers. Real-world usage data is now available for developers to improve the quality and usability of their products quickly. We refer to the IoT development process as a feedback loop.

Teams that have successfully leveraged agile methods to improve software delivery now want to carry that over to hardware, to apply the same agile methods to mechanical, electrical design and manufacturing processes.  They are challenged with connecting software, hardware and device services components together and linking together the engineering disciplines that deliver these components of the completed product.

Hardware and software configurations evolve at different rates, and keeping track of which software goes with which hardware requires clear connections. As product complexity increases, each component’s configuration and its linkages across the overall product configuration can soon become unmanageable without a system to support the process.

Product lifecycle management

In product lifecycle management (PLM), hardware configurations are managed through the Bill of Materials (BOM). There are several types of BOM including the electrical design, mechanical design and manufactured assembly, such that now a “product” is actually a “system” – and you need a way to trace the parts of that system and their dependencies across the phases of the product development (and deployment) lifecycle with clear linkages. In IoT, this is sometimes referred to as the “digital thread”—the traceability through the nodes of a BOM through its lifecycle and back.

In application lifecycle management (ALM), software configurations are managed through software change and configuration management tools. The capabilities of these tools have become increasingly critical to successful software development as software complexity has increased, software supply chains of different component vendors have evolved, and agile methods have become important to the timely delivery of software.

In the context of IoT development, linking your software configurations with your hardware BOMs is vital to successfully delivering a quality product that can be evolved in the light of changing customer needs informed by operational feedback. Rapid and accurate understanding of the impacts of changes across the whole IoT product, including all aspects of hardware and software, is critical to the IoT lifecycle.

The linking of the worlds of ALM and PLM in this way is a difficult challenge; PLM and ALM tools are typically supplied by different vendors and are often deeply embedded in an organization’s engineering and development processes. ‘Rip and replace’ of existing environments often simply isn’t an option; you need connectivity between the worlds of PLM and ALM.

Linking ALM and PLM is a big step toward digital transformation of product development and realizing the “digital thread”.

Learn how IBM is linking ALM and PLM.

 

The post Connecting hardware and software lifecycles to build the Internet of Things appeared first on Internet of Things blog.

Internet of Things blog

Connecting Nepal’s Earthquake Affected Communities with a Sustainable Model

Beyond the Net Journal

Nepal’s rural population remains largely disconnected from the Internet. The problem is further aggravated by the devastating 7.8 Richter scale earthquake and the subsequent aftershocks that have been shaking Nepal since April 2015 and that left nearly 9,000 people dead.

The Internet Society Nepal Chapter, in partnership with the NPO “Forum for Digital Equality“, led a successful project to reduce the digital divide by facilitating the establishment of three Community Learning Hubs. The project, supported by The Internet Society Beyond the Net Funding Programme, set up the centers in three Nepali districts that were badly affected by the earthquake: Dhading, Sindhupalchowk and Dolakha.

Each Hub is being visited 100/day by community members. More than 1500 more people are now accessing the Internet for free. To ensure a sustainable model for the project, services like printing and scanning are charged. The raised revenue is used to pay for operator salaries, repair and maintenance services.

Goma Shrestha, community ITC operator, proudly explains, “We started “eSewa”, an online payment gateway. Villagers used to go to the market to recharge their mobile and cable service, but now we have facilities in our own community”.

The digital divide between Nepali rural and urban areas has negative consequences when it comes to education. For children in low-income school districts, inadequate access to technology can hinder them from learning the skills that are crucial for their future. In collaboration with government institutions, the Nepal Chapter installed free and open content in the computer laptops provided to the learning hub. The project trained 6 ICT operators to help local students learning new skills.

“I come here to learn computer,” a 15 year old boy, Pradip Waiba, says with enthusiasm. “I have learnt how to type and use programs like Powerpoint, Excel and I talk online with my dad and uncle that are abroad.”

The Chapter has started a discussion with the Department of Information Technology of the Nepal government and with some organizations that are developing online courses for the school and digitizing hundreds of Nepali books. The educational content will not only be useful for students but also for the community members to expand the horizon of their knowledge.

“The project model could be transferred to others districts. Different rural communities are interested to collaborate with us.” says Suraj Adhikari, treasurer of the Nepal Chapter. “We received support from the popular Nepali comedians Dhurmus and Suntali. They started a foundation to rebuild the houses destroyed by the earthquake in the same village where we were establishing a computer hub. They provided us a room to setup the center.  Most of the people are using Internet for the first time because there was no such infrastructure before.”

Watch the video to hear from their voices.

Follow us on Twitter

Do you have a great idea? We are interested in your project. We are looking for new ideas from people all over the world on how to make your community better using the Internet. Internet Society Beyond the Net Funding Programme funds projects up to $ 300.00 USD.

The post Connecting Nepal’s Earthquake Affected Communities with a Sustainable Model appeared first on Internet Society.

Internet Society

Eclipse Hono – Connecting large numbers of IoT devices

The value of an IoT solution often correlates directly to its ability to connect many different devices and integrate them into higher-level solutions. Although all solutions combine devices using a unique integration strategy, the reliable, secure, and scalable connection of devices is always crucial.

Connectivity is therefore best handled as a separate service, independent of a solution – and this is exactly what Eclipse Hono aims to accomplish.

Overview

Eclipse Hono is written entirely in Java. It also provides a uniform messaging infrastructure for IoT solutions. Eclipse Hono offers:

Dejan Bosanac

  • Senior Software Engineer @ Red Hat
  • Committer @ Eclipse Foundation / Apache Software Foundation

Follow Dejan on Twitter

  • a horizontally scalable microservice architecture
  • a design for container-based cloud environments (based on AMQP 1.0)
  • load protection for all microservices using AMQP 1.0 flow control
  • protocol adapters for different IoT protocols
  • handling of different communication patterns
  • a tenant-based security model, including authentication of device

Solutions integrated with Eclipse Hono are freed from the details of device connectivity, and can instead concentrate on providing business value.

IoT communication patterns and QoS

Most messages in IoT setups are usually telemetry messages: data flows from devices to solutions. Messages of this kind usually need not be guaranteed of reaching their destinations and can be handled especially efficiently because there are no acknowledgements involved (QoS “at most once”). A typical type of telemetry data is sensor data that is sent within short time frames.

Paolo Patierno

  • Principal Software Engineer @ Red Hat
  • Committer/Lead @ Eclipse Foundation

Follow Paolo on Twitter

Telemetry messages that absolutely must be delivered (QoS “at least once”) are called events, which are always acknowledged to the client and occur infrequently by comparison. Typical events include alarms that need a guarantee to reach the solution and must never be dropped.

The other direction is called command and control: data flows from solutions to devices. This addresses the control of actors, or in general messages initiated by the solution, and will be provided in future versions of Eclipse Hono (versions > 0.5).

Hono in production setups

Eclipse Hono defines APIs for all aspects of device connectivity:

Karsten Frank

  • Senior Software Developer @ Bosch Software Innovations
  • Committer @ Eclipse Foundation
  • Spring Core 4.2 Certified Developer

Take a look at Karsten's GitHub page

  • sending and consuming message payloads for different communication patterns
  • handling of device identities and device credentials for secure communication
  • authentication of devices and microservices

Because the handling of device identities is assumed to be specific to a production setup, it is provided by a simple file-based implementation. Due to the use of Spring beans and the Vert.x event bus, this implementation can easily be substituted by a database implementation.

The same applies for the (file-based) authentication server, which may be replaced with other implementations.

Bird’s-eye architecture view

There are several different categories of Hono components:

Infographic showing the different sections the components of Eclipse Hono are split into.

Protocol adapters

Protocol adapters connect devices to Hono. Each covers a specific protocol and is responsible for the authentication of devices by querying the device registry.

Hono provides the following protocol adapters:

  • HTTP
  • MQTT
  • Eclipse Kura-based gateways

Custom protocol adapters can be added by using the APIs of Hono Core.

Hono core

Hono core consists of:

  • the Device Registry, implementing
    • the registration and activation of devices belonging to a tenant
    • the provisioning of credentials for devices
  • the Auth Server, implementing
    • the construction of security tokens to support the authentication of a client
  • Hono Messaging, implementing
    • the messaging APIs for telemetry and event messages
    • verification of compliance with the APIs
    • the forwarding of messages to the AMQP 1.0 Network

AMQP 1.0 Network

The AMQP 1.0 Network decouples Hono’s core microservices from solution applications. It provides a scalable messaging infrastructure that supports different communication patterns with varying quality of service levels.

A few properties of the AMQP 1.0 messaging protocol make it an ideal candidate for this purpose.

First, this is one of very few messaging protocols that is truly symmetrical. It does not require a broker as an intermediary in the message exchange process. It supports both “store and forward” (brokered) and direct messaging communication patterns. The symmetrical nature of AMQP 1.0 allows Hono to use different communication semantics and different messaging components to handle various flows of messages.

The entry gateway into Hono’s AMQP messaging system is the Apache QPid Dispatch Router. It provides direct communication between producing and consuming endpoints. Unlike a broker, the router never takes ownership of messages; it instead simply passes AMQP packets between different endpoints. This means that, from a messaging perspective, the router is basically stateless. As such, it is much more vertically scalable than a message broker. In addition, it is far easier to scale it horizontally in a cloud environment – as we will see in a moment.

Another important feature of AMQP 1.0 is its flow control mechanism, which is implemented directly in the protocol. This means that consumers will, at every point, declare their capacity, or how many messages should be delivered to them. This information is propagated by the router, and producers of messages can be throttled to the speed of consumption.

Infographic showing the telemtry flow in regard to Eclipse Hono.

It is now easy to see why Hono uses only routers to deliver telemetry messages to the solution tier. These messages typically exhibit a large volume, which requires scaling – but at the same time, we can afford to lose them if something goes wrong.

In the example deployment, Hono comes with a single router for simplicity. In real-world deployments, routers are usually deployed in networks. Often, full-mesh networks are used. With such a topology, we achieve two things. First, we improve the scalability of the system as clients are distributed over different routers. Second, we improve the reliability of the system, as it can easily survive crashes of one or more routers while remaining functional.

We have covered messaging needs for telemetry traffic. But what about events and command messages that require a genuine guarantee of delivery? Dispatch routers can be configured to “auto link” certain addresses to external AMQP 1.0 containers. In this way, we can route messages through the broker queue and provide “at least once” delivery guarantees for events and commands.

In the default deployment, Hono uses Apache ActiveMQ Artemis Broker. It provides a scalable AMQP 1.0 message broker; its queuing capabilities are used to store event messages.

Infographic showing how Eclipse Hono employs the Apache ActiveMQ Artemis Broker.

Of course, you can use any AMQP 1.0-compatible message broker for this. Or provide more scalable and more reliable solutions by using broker clusters and high-availability configurations. In addition, the default deployment of a single router and broker can be replaced with a scalable AMQP 1.0 cloud messaging platform – such as the one described later in this article.

Solution tier

All solutions connect to the AMQP 1.0 network and receive messages from the messaging endpoints.

/telemetry/<tenant>/<device>

or

/event/<tenant>/<device>

They do not themselves need to integrate specific IoT protocols and benefit from the flow control of the AMQP 1.0 network.

The User Guide portrays examples of how to write solutions.

Monitoring infrastructure

Hono Messaging and the protocol adapters report different kinds of metrics to an InfluxDB, which can be viewed using the Grafana dashboards provided. Please refer to Getting Started for details.

APIs and their endpoints

Hono’s internal APIs are defined as AMQP 1.0 endpoints:

Infographic showing the components of the Eclipse Hono API.

Protocol adapters use Hono’s internal APIs to:

  • authenticate the device using the Credentials API
  • check the status of the device using the Registration API
  • forward device messages to the AMQP network using the Telemetry or Event API

As with the AMQP 1.0 network, flow control also enables the load protection regarding devices.

The Device Registry also implements RESTful variants of the Registration APIs and the Credentials APIs in order to support the administration of devices. This leverages the use of CLI tools like curl and simplifies implementation of a complex Device Operations Console (which is not part of Hono itself).

Deployment options

All microservices are built as Docker images and are available on Docker Hub. The following container management systems are supported based on the Docker images:

  • Kubernetes
  • OpenShift
  • Docker Swarm

The supplied deployment scripts start a preconfigured orchestration of the microservices for a fully functional installation. They are contained in Hono’s example module.

Deployments can be executed either on premise or hosted in a public cloud. On premise deployments work well for a small number of devices or test setups; a public cloud deployment is better for large installations that can scale dynamically per number of connected devices.

You can set up Hono yourself or use the sandbox deployment, which is accessible at hono.eclipse.org. The following steps assume you have Hono running locally:

  1. Register a device by using the REST API of the device registry

curl -X POST -i -H ‘Content-Type: application/json’ -d ‘{"device-id": "4711"}’ http://localhost:28080/registration/DEFAULT_TENANT

  1. Start a consumer; refer to Getting Started for details.
  2. Upload data using the HTTP adapter.

curl -X POST -i -u sensor1@DEFAULT_TENANT:hono-secret -H ‘Content-Type: application/json’ –data-binary ‘{"temp": 5}’ http://localhost:8080/telemetry

  1. Observe the consumer receiving the data.

Scale it up!

Hono is fundamentally designed for horizontal scalability. This is reflected in its microservices architecture:

  • protocol adapters can be scaled independently from the messaging infrastructure itself.
  • solutions are decoupled from Hono by the AMQP 1.0 network layer, which can be scaled independently from Hono itself.
  • the device registry is separated from the messaging components and, consequently, can be scaled independently as well.

You can use the scaling strategy of your container management system to scale the microservices you need. The internally used AMQP 1.0 protocol is designed for scalability and very large networks.

EnMasse – the elastic messaging infrastructure

Because Eclipse Hono is not itself a messaging system, it needs an underlying messaging infrastructure to work. Messages are exchanged between all internal components and sent from external devices to and from business applications. We refer to this type of infrastructure as the “AMQP 1.0 Network” in the overall Eclipse Hono architecture. As noted elsewhere, the off-the-shelf solution consists of the Qpid Dispatch Router and the ActiveMQ Artemis Broker.

The Eclipse Hono architecture was designed and developed in such a way that the underlying messaging infrastructure can be modified – provided that it is based on AMQP 1.0. This means you can use RabbitMQ with the AMQP 1.0 plugin, for example, or any other messaging broker implementing the AMQP 1.0 protocol.

Big numbers? We need elasticity!

When it comes to supporting a large number of connected devices and high throughput in terms of exchanged messages, the “single router, single broker” solution has its limits.

The messaging infrastructure needs to grow, and the scalability becomes the most important criterion for allowing Eclipse Hono to handle devices and consumers as well as the tremendous traffic associated with them.

A major problem in this case is deployment. How can we deploy the messaging infrastructure simply, without having to address the related complexity? Besides scalability, you also need high availability and resiliency.

In short, your messaging infrastructure needs to be elastic so it can support spikes in the numbers of connected devices and traffic generated, so that computational resources are then used productively. It would be a waste to run too many AMQP 1.0 brokers for a low number of devices and for low traffic. At the same time, such an infrastructure needs to grow as numbers increase. As that can change frequently, you need elasticity.

The answer? The EnMasse project!

How to address all the challenges mentioned above? The EnMasse project comes to the rescue!

EnMasse is an open source “messaging as a service” platform which simplifies the deployment of a messaging infrastructure both “on premise” and in the cloud. It provides the scalability and elasticity needed to support the messaging requirements for IoT use cases.

Moreover, EnMasse supports all common messaging patterns (request/reply, publish/subscribe, and competing consumers) and two main protocols: AMQP 1.0 and MQTT. Adding HTTP support is on the roadmap.

EnMasse provides multi-tenancy, meaning that different tenants can share the same infrastructure – but are isolated from each other. Finally, it provides security with respect to securing connections using TLS, but also authenticating clients using Keycloak as the identity management system.

Infographic showing how EnMasse works.

Another aspect that makes EnMasse appealing to use with Eclipse Hono: it is completely containerized and runs on key container orchestration platforms such as Kubernetes, Docker Swarm, and OpenShift. It is an excellent complement to Hono’s microservice architecture and deployment models portrayed in preceding paragraphs.

Infographic showing how EnMasse fits into Eclipse Hono.

As you can see, EnMasse offers all the features needed to be the messaging infrastructure that supports Eclipse Hono. It is easy to deploy both together in OpenShift; you can find more information on that in the step-by-step guide.

Conclusion and outlook

This article covers the basics of the Eclipse Hono project as well as describes its APIs, architecture, and deployment options. There are many things still to come in this field. The Telemetry and Event APIs we described are only the first that have been implemented. Next on our to-do list: the Command and Control and Tenant APIs.

The Command and Control API will provide a way for business applications to reliably send commands to the devices. The Tenant API will provide platform operators with the resources necessary for managing tenants (accounts).

We will also improve the EnMasse integration, particularly as regards shared security models and scalability testing.

We hope that we have increased your interest in IoT connectivity in general and the Eclipse Hono project in particular. We have a lot planned, and hope to see you in the community!

The post Industry 4.0 in 2017 – a quick look at the powerful 7 appeared first on Bosch ConnectedWorld Blog.

Bosch ConnectedWorld Blog

Connecting the World One Car at a Time

Connected vehicles are finally coming into their own and establishing themselves in the marketplace. Today, about 35 percent of new vehicles are connected to the internet. They’re packed with sensor technologies that monitor driving, safety and vehicle health conditions. By 2020, enhancements for internet-enabled vehicles are expected to be among the top downloads from app stores. It’s an exciting, emerging space to provide new value, transform the consumer’s experience and open new revenue streams.

But what about the hundreds of millions of vehicles that will remain on roads for a long while yet that are not connected? The last serious estimate of the number of cars on the roads globally was 1.2 billion. It’s also estimated that there will be a quarter-billion connected cars on the roads by 2020. That still leaves about a billion cars that are not connected.

Making connections happen

Figuring out how to bring connected vehicle services to this vast population of disconnected vehicles presents an exciting opportunity. AirWire Technologies, leveraging its Connected Car OBD Solution, is working with IBM to implement its connected car and IoT services platform powered by IBM Watson IoT for Automotive. AirWire’s connected car cloud services work in conjunction with its proprietary Connected Car OBD solution

The AirWire connected car device attaches to the vehicle’s OBD II port. This port is available on any car newer than 1996. The device provides uninterrupted connectivity through an advanced 4G LTE network. It seamlessly uploads important vehicle data to the cloud for analysis, enabling apps and services for the consumer’s smartphones and other mobile devices. The device also acts as a hotspot, enabling wireless Internet inside the vehicle without having to stream data over Bluetooth through the user’s smartphone.

The AirWire connected car device attaches to the vehicle’s OBD II port. This port is available on any car newer than 1996.

Vehicle owners can analyze vehicle performance, driving efficiency, driving safety and vehicle health information using AirWire’s connected car cloud services. The AirWire cloud services model enables our operator partners to enter the vehicle IoT space seamlessly, quickly and with minimal network effort. Airwire’s device and the Personal Assistant App for connected cars and IoT services on IBM Watson platform is a voice-activated personal assistant in vehicles. It is AI-enabled as it recognizes previous travel patterns and asks relevant questions to help drivers with a variety of needs from routing to commerce to understanding the surrounding environment.

With AirWire, vehicle owners can analyze vehicle performance, driving efficiency, driving safety and vehicle health information using AirWire’s connected car cloud services.
The AirConnect app acts as a personal assistant to drivers, and allows them to use voice commands to communicate with their vehicles.

IoT for Automotive

IBM’s IoT for Automotive provides a purpose-built, connected vehicle solutions that is designed to handle high-volume, high-velocity data consumption and analytics that the automotive industry demands. It’s well suited to pair with AirWire’s offering to give drivers comprehensive information about their vehicles. IoT for Automotive also bundles services such as driver behavior analytics to score and provide feedback on driving performance.

“Our partnership with AirWire enables the data collected through their in-vehicle connected car device into a cloud platform harnessing the power of cognitive computing to connected vehicles, sensors and systems that comprise the automotive IoT space, helping transform how vehicles are owned, operated and maintained,” said IBM executive, Dibbe Edwards, vice president for Watson IoT Connected Products.

“AirWire is excited to partner with IBM, an established leader in the IoT space, enabling our connected car and IoT services platform through IBM’s innovative IoT for Automotive solution to connect vehicles over any network in any part of the world. All of our operator partners, automobile OEMs and vehicle owners will benefit from the power of IBM IoT for Automotive to help them connect vehicles in the IoT space,” said AirWire CEO, Debashis Bagchi.

Global pilots starting soon

AirWire is initiating pilots globally of the AirWire connected car and IoT services platform powered by IBM Watson IoT for Automotive. The initial targeted pilots will be in India, Philippines and the U.S. A worldwide launch follows soon thereafter. The AirWire Connected Car app “AirConnect” acts as a personal assistant to the drivers and allows them to communicate with their vehicles using voice commands.

Look for availability of the app soon in both IoS and Android versions. Find more information about Airwire please visit their site. To find out more about IBM’s IoT for Automotive, visit our site as well.

The post Connecting the World One Car at a Time appeared first on Internet of Things blog.

Internet of Things blog