Libelium: Wiring The Internet Of Things From Spain

By Internet of Things (IoT) No Comments

Libelium and a Vision of Smart Cities

One does not usually think of Spain as startup nation (see postscript The Gain in Spain, below), but a small Spanish company Libelium has been getting much attention, especially in Europe, thanks in no small part to its young charismatic CEO Alicia Asin Pérez. Libelium specializes in sensors and sensor networks for the Internet of Things (IoT) and boasts multiple projects especially interesting Smart City applications (although the company’s website does not make much effort to clarify the relative role of Libelium’s hardware vis-a-vis that of the prime systems integrator.) Libelium’s management did an admirable job bootstrapping the company to a revenue to estimated 6 million Euros without any external funding except for cash won at various technology and innovation competitions.

Libelium’s product portfolio comprises wireless gateways and sensor boards designed to facilitate easy Internet connection of sensors using common industrial protocols such as RS-232, RS-485, Modbus and 20mA current loop.  On the wireless side, Libelium support any number of long range, midrange and short range protocols. The ideas is to provide an open source sensor platform enabling system integrators to implement reliable IoT solutions.

The company leadership likes to talk about how Libelium is driving the technology evolution of smart city applications.  But given its size and position, what future role can Libelium play? Do IoT-enabled sensors in an already crowded and over-hyped space suffice to sustain the company’s momentum? The company’s spokeswoman I spoke with wasn’t very helpful in articulating the company’s strategy, so here is my take.

As I’ve discussed and written in the past, the value realization of IoT applications takes place at the data aggregation, analytics and decision-making end of the IoT technology stack – the opposite end of where Libelium’s technology is deployed. Sensors and wireless connectivity are obviously crucial, and we should expect to see continued improvements in sensor technologies, miniaturization and low power solutions. But the marketplace is already very crowded with vendors that provide distributed wireless communication, and connectivity in itself is rapidly becoming a commodity. See, for example, Forbes article 6 IoT Startups That Make Connecting Things To The Cloud A Breeze. And with the industry of “things” on hyperdrive, we can expect to see multitude of new companies pushing into the space, leveraging platforms such as Raspberry PI, Arduino, Intel Galileo and Edison, and other low cost development kits.

The horizontal product and market strategy places Libelium in the midst of the crowd and may not provide sufficient functional differentiation and, more critically, barrier against this low cost competitors.

On the other hand, Libelium has developed relationships with key systems integrators and technology providers, including Axeda (which, for some reason is described by Libelium as a cloud service provider), IBM, Microsoft, Sentilo, Telefónica and ThingWorx, which offers very good reach and brand exposure, especially for a company of that size. The company open source community boasts 2,000 developers in 75 countries.

Nevertheless, the product portfolio and capabilities in a highly competitive space and the dependency on lead systems integrators limits the company’s ability to play a leadership role in Smart City applications, or, for that matter, in any vertical IoT application. Indeed, the company’s spokeswoman vehemently rejected the notion of any of vertical specialization, but couldn’t articulate how the company intends to remain a horizontal technology provider and support the pervasive Smart City sentiment at the same time.

To raise the barrier to entry and defend against commoditization, Libelium should consider leveraging the experience and exposure it gained to develop targeted expertise and a stronger competitive position. This doesn’t mean abandoning the “plug and sense” strategy to provide horizontal telemetry solutions to any sector. Rather, use the product components and systems integrators ecosystem to focus on a manageable number of vertical segments and offer a comprehensive set of capabilities and reusable solution components to accelerate deployment and time to value, especially at the business facing end of the IoT stack.

Postscript: The Gain in Spain

Spain is home for a number of IoT startups, including, in addition to Libelium, startup companies such as Mildmac, Carriots and EIOT. Spanish telephone carrier Telefónica has a global M2M business unit. Perhaps surprising to some, all major cities in Spain boast some type of Smart City imitative, although the market for hardware provides, overall, is quite small (most of Libelium’s revenue comes from outside of Spain.) As importantly, the Center for the Development of Industrial Technology of the Spanish Ministry of Science and Innovation supports IoT and Smart City initiatives. With this level of activity the risk market will have to undergo consolidation, leaving some upstarts by the wayside.

 

Broken Televison

Television, Heal Thyself! Smart Service and the Internet of Things

By Internet of Things (IoT), Manufacturing, Service Lifecycle Management (SLM) No Comments

Television, Heal Thyself!

I was asked by an investment banker to comment on business applications of the Internet of Things (IoT) technologies and specifically on IoT technologies and business models that pertain to this awful word “servitization”: equipment service, remote monitoring, predictive diagnostics and so forth.

Their interest in the topic piqued following a recently published article contrasting the author’s own poor television repair service experience with a hypothetical—but presented as realistic—repair scenario utilizing advanced IoT-based diagnostics. The scenario is given below. I changed the language but kept the essence of the original script intact. Read More

The Money Lender and His Wife (Quentin Metsys, 1514)

Searching for Value in the Internet of Things

By Internet of Things (IoT), IT Strategy 4 Comments

The Internet of Things is Not About Things, Nor is it About the Internet

It seems not a day goes by without seeing breathless headlines predicting the magnitude and the impact of the Internet of Things (IoT).  For instance, Morgan Stanley estimates that by year 2020 there will be 75 billion devices. Harbor Research, at the end of the spectrum, forecasts an order of magnitude lower estimate: 8 billion. Cisco offers 50 billion, Gartner counters with 26 billion, and IDC is right in the middle with a forecast of 30 billion connected devices.

Do you get a feeling that they may not really know? Perhaps they are talking about different “things”? And, at the end of the day, does the number of connected devices really matter? And to whom? Read More

Number 48 (Jackson Pollock, 1949)

The Fallacy Behind Counting Lines of Code

By Automotive, Aviation and Aerospace, PLM 4 Comments

Mercedes-Benz vs. F-35

A while ago I attended a discussion about vehicle software development and maintenance. The presenters discussed the increased complexity in automotive software, especially in in-vehicle infotainment (IVI) and the advantages of remote over the air firmware update (FOTA).

To demonstrate the magnitude of the problem, one of the speakers used oft-cited statistics contrasting the number of lines of code (LOC) in the software in a modern car and of a military aircraft. The statistics (attributed to IEEE) were:

  • Current generation aircraft        1.7 Million LOCs
  • Next generation aircraft (F-35)   5.7 Million LOCs
  • Modern passenger car                100 Million LOCs

Do these figures mean that the software in a passenger car packs more functionality than an F-35?  As complexity increases exponentially with the number of lines of code, do the numbers indicate some 500-fold increase in the complexity of vehicle software? Read More

BigLever and Aras Deliver Product Line Engineering Integration

By Mergers & Acquisitions, PLM 3 Comments

Product Line Engineering: Rethinking Product Development

BigLever Software, a provider of product line engineering software, announced today that the company has partnered with Aras Corp. to deliver an integration between product line engineering (PLE) and product lifecycle management (PLM) software suites.

The integration enables product designers to define product options and variants in BigLever’s Gears software and communicate them directly to Aras Innovator PLM tool to generate a complete bill of materials for each product variant. This helps configuration engineers handle the increased complexity in product architectures, and, in particular, the proliferation of embedded control software modules.

To understand the significance of this announcement, a brief, somewhat technical, explanation of PLE is necessary.

What is PLE Anyway?

The need for higher density and richer repertoire of product functionality to meet consumer expectations and establish market differentiation continues to burden brand owners. Marketers and designers need to add product features at a high pace, frequently utilizing embedded electronics and control software to add functionality and configure products to specific markers and demographics. The result is often a large and complex set of product configurations and variants that include not only hardware and software components, but also test scripts, manufacturing work instructions, compliance certificates, user documentation, and more.

In a typical product development process, market requirements are decomposed into functions that are mapped onto a hierarchical bill of materials (BOM) structure. Individual BOM items are grouped to form the configurations and option packages that can be manufactured and sold to consumers, such as the option to add power windows and locks to a car, or a higher end PC “bundle” that includes expanded memory capacity and a fast graphic card. Frequently, rules have to be defined for “allowable” configurations to reflect design constraints, product pricing strategy, and other technical and business considerations.

Many engineering organizations find the complexity of culling BOM items (and their associated non-BOM objects) and creating “packages” for design, manufacturing, sales and support extremely difficult to handle. And the fact that many product companies use manual processes supported by an assortment of databases and spreadsheets to manage product configurations doesn’t do much to alleviate the situation.

Inverting the Process

Product line engineering takes a different approach to decomposing requirements into product design variants. Rather than starting the configuration process with an existing BOM, PLE starts with the set of “features” that are put together to form valid functional configurations as defined by the product functional requirements; for instance, a power windows “package.” The important distinction is that features do not have to correspond to physical parts. Rather, they describe functionality units linked directly to functional requirements and managed at a functional level.

In essence, one can see the product description in PLE as a bill of features containing all physical and virtual artifacts such as mechanical, electrical, wiring, software, calibrations, requirements, designs, test cases, documentation, and so forth.

The bill of features isn’t limited to itemizing features that must be engineered and manufactured in the traditional sense.  It can include, for example, the different warranty terms and bundled services for each configuration.

As importantly, features are canonical and not product or design specific, and therefore are easy to understand and manage even before the actual design has started. Feature “dictionaries” can be shared and reused across multiple products in a manner that reduces configuration management complexity and errors.

PLE and PLM

With a direct PLM-PLE integration such as the one demonstrated by Aras and BigLever, configuration engineers do not use external documents to configure a BOM for a specific product and hope that all the needed components (and only these) are included. Instead, an engineer uses Gears, BigLever’s PLE software to select the desired functionality “package.” Gears generates the list of features for each desired configuration and send it directly to Aras Innovator to generate the bill of materials.

Why is this Important?

As discusses earlier, some organizations find that managing complex product configurations and options can be a labor intensive, time consuming and error prone activity.

One outcome of this complexity that is seldom discussed openly is its impact on product testing. Because of the large number of product variants and seemingly endless number of permutations and dependencies between individual parts and subsystems, the generation of relevant and effective test cases is a dauntingly complex and time consuming task that still does not guarantee complete test coverage. Consequently,   products undergo insufficient testing, precious resources go to waste, and project schedule and quality are jeopardized.

With PLE, only the relevant features—and therefore only affected parts and software modules­­—are selected. If test cases for a specific configuration exit, they will be included automatically, or, new ones can be designed and included in the bill of features for future use.

Implications

The integration of between Gears and Aras Innovator can help companies reduce complexity, enhance efficiency, and improve the accuracy and completeness of product configurations.

Aras users that manage variant-rich product portfolios would benefit from the new ability to manage requirements and complex feature set in Gears and keep Aras Innovator BOMs in sync.

Gear’s users, not all of them are also Aras users, should consider implementing a small proof of concept PLE project using Aras Innovator to gauge the benefit of a direct PLE-PLM gateway firsthand and discuss it with their PLM software vendor.