Bulldozing the digital chaos: Who will harvest vast data from Construction machinery?

This 5-part article speculates on current state of Construction equipment IoT. There remains a conundrum faced by many Construction related product and innovation managers, who at the same time are curious and anxious to see a rise in IoT use cases yet remain frustrated by the continued fragmentation.

Why, what, and how are loads of data emerging from a heterogeneous mix of hardware on the construction site? What may shift this from being a problem to becoming part of the solution for increasingly digitally-connected projects?

A key part of the answer I contend would be for equipment OEMs to band together to declare (if only, for competitive reasons) and make “open” a set of common data for any purchaser willing to pay a small surcharge for a data-plus version.

Introducing the case for change

Opening Pandora’s bulldozer: This data part is mine, this is yours, and this we share. Where’s the dividing line?

Most original equipment manufacturers (OEMs) of machines, equipment, and tools used for Construction and Industrial work actively are adding and exploring further digital features. These will create new mountains of data. While the OEMs can find useful ways to further process this data, they are wrong to exclusively hoard this and lock out users from easier access. Savvy companies managing fleets of equipment and other applications must have clearer access to certain data sets not sensitive or critical for the machine’s operation. Yet few manufacturers have resolved to give users open access to some or all data.

What are the manufacturers thinking? There are legitimate worries about cost, complexity, and confidentiality. Yet many of these are overblown. They are fanned by legal departments, hardware product managers completely inexperienced with Software and the interconnected cloud ecosystem, and the absence of digital interoperability standards. Opening more of this data will become increasingly useful for end users to integrate within their construction site and company’s emerging Construction digital ecosystem. Data are instead siloed within the manufacturers’ own applications; which brings little use.

The range of Software connecting sites with back offices is expanding rapidly; but Hardware makers are lost in this new digital ecosystem and cannot fathom why users could possibly want a “connected ladder”. That creates an opportunity for new entrants. Ambitious heavy machinery makers, with expensive units that would suffer negligible change of price in percentage terms if adding $5 to $20 in manufacturing cost for an added sensor stack; imagine themselves and their own Software as the beneficiary of this data. Rather than aspiring to “Big Tech” greatness and leveraging digital to try to outdo traditional competitors, equipment manufacturers should simply broadcast certain data openly or allow open plug-ins for users to process these as they wish. Why do users need it; they should tell manufacturers, “It’s none of your business!”.

Recently as a test of data access, I used my recently expired European residency to make GDPR data requests from several digital services including my former car, ride-hailing mobile application, and social hospitality booking service. All of them honored the request in spite of the 2019 expiration. Data nerds living in Europe can easily run this data, reaching out to their favorite services. One of these I checked was fantastically organized: offering a clear process which was automated, fast, and complete. Others literally struggled, buying time with e-mail clarifications and apologies, and piecing together disparate parts into sending personalized apologies for missing deadlines. Several asked why I needed this. None of their business! It was just a test, but illustrative. If digital native companies struggle, imagine how traditional manufacturers will squirm when outlier customers become motivated to start requesting clearer access to their digital stockpiles in jurisdictions providing the right to ask.

In the spirit of increasing regulation, driven by Europe and under consideration elsewhere, a portion of usage data clearly belongs exclusively to the user, for his or her own workflows. Giving Construction and Industrial customers easy access to metadata neither core nor sensitive to the inner functioning of their equipment will be a win-win for users and manufacturers. Let me lay out the case for OEMs to do exactly that, which variables they ought to provide (as a standard?), and suggest a few scenarios how this could play out with several data processing champions.

Why such data chaos

The Smart Home should be far less complex than the Smart Jobsite, yet still took 20+ years to organize into platforms. The Smart Construction site will have 10 times wider range of equipment and use case scenarios, yet 10 times fewer years to figure this out.

The jobsite — whether a new office tower, renovating a retail space for a new tenant, or virtually any project — hosts a menagerie of equipment: from small drills, to scissor lifts, to massive cranes. The day all this equipment becomes connected may still be a decade or more from reality. The smart home can be easier to picture, has had longer to incubate, and is finally reaching a type of mainstream adoption. Analogies should be used with caution, but may be helpful in describing the principle challenges and potential path forward.

Picture the variety of brands making items in your home that run on power: now multiply by a factor of ten. As consumer electronics makers see growth potential from adding new “Smart” and “Connected” features, so do many professional equipment makers. It’s early, but starting. Smart home devices are finally starting to harmonize onto common platforms by the likes of Google Nest and Amazon Alexa. The Smart Construction site clearly lacks such a lead “consolidator”. That’s both an opportunity and a threat, for any of the companies whether startup or multinational corporation with a stake in how this ecosystem evolves.

Problem 1: A niche device will follow a standard, not set its own.

A threat to OEMs with major brands across segments of equipment could be that their own standards and formats are relegated. Worst, user adoption blows in the wrong direction from their own systems, condemning manufacturers’ own proprietary digitization initiatives to the same fate of low adoption of disgraced efforts by certain brands to champion their own smart home platform. Consider the garage door manufacturer: important for security, used daily, yet completely useless for integrating into other feature sets. Yet multiple brands would still imagine, a set of consumers motivated enough to download and use their own apps.

A connected home vision was predicted for decades, for example by Bill Gates in his 1995 book, “The Road Ahead.” What have we learned? No matter if it installs in 20 seconds or takes 60 seconds to register, you frankly do not want to deal with however your garage door opener OEM conceptualized their own vision of IoT. You want them to be on Amazon, or your other Tech giant favorite environment. You hardly need the garage door opener App — 99% of the time it’s one-click to operate not unlike a basic drill. You could care less to pay their connected monthly subscription let alone download their App. However, if you use Apple HomeKit, you’d welcome the integration and try it out.

Problem 2: “Smart” something piques curiosity. “Smart” everything leads quickly to confusion.

In the past 5 years, a wide range of new connected solutions jumped into the pages of industry-leading media like ENR and BuiltWorlds. While larger cost heavy machines in civil construction (not unlike your latest rental car) have long relied on telematics boxes to monitor and transmit status and performance, helping avoid breakdowns, theft, and misuse, suddenly new categories of connected or so called “IoT” devices have emerged. There are even robotic dogs capturing all the views on YouTube, offering to scramble up stairs with a wide-angle camera to help with inspections and progress monitoring.

Stepping back from robotic dogs, it is useful to take stock of the huge range of existing Construction hardware. The website of a leading U.S. rentals company organizes its public catalog into 18 categories that collectively include a total of 115 subcategories.

Bluetooth connectivity: why not? Tether to Smartphone, and get instructions, theft protected access, or activity logs.

One worry: digital chaos will reign if all brands develop Apps and expect users to embrace each. This already starts to happen. Some manufacturers even list multiple Apps on Google Play or Apple iOS store, perfectly natural for their respective business divisions and utterly baffling to its infrequent users. Now imagine dozens if not hundreds of Apps, each with its own look and feel; each with its own functionalities. Assuming each of the 115 subcategories from a major U.S. rental company’s equipment webpage has 4 or 5 major brands, there could be well over 500 companies with potential “connected” solutions already or soon to arrive. The March 2020 CONEXPO trade show in Las Vegas cites over 2400 exhibitors planning to be there, so it may be a reasonable estimate to figure there are upwards of 500 companies potentially exploring their own digitally-connected opportunity.

No single Smartphone could fit this, nor single worker could tolerate this.

Still, an ambitious large Construction Group CIO or Rentals company CIO might aspire to tapping into this data opportunity. Where do they start?

Construction work is segmented by many trades and specialties. And if a company specializing in one given trade has a warehouse with 100 brands of equipment, it’s likely that 80% of work labor hours are spent with only 20% of equipment type. A best-case assumption of “regular” use of 20 brands still implies too wide a variety to go in-depth with individual systems from any other than your most important manufacturers. Chances are that controls, Apps, interfaces, and data availability from even major manufacturers varies so widely that harmonization would be impossible for any company other than a rental company installing after-market IoT boxes or a startup with an ambitious, quixotic idea.

Users and the hundreds of thousands of small businesses in the construction trades will not be delighted about dozens of brands using their own standards. Younger workers grew up surrounded by digital everything and may be more open to trying features, though most workers in the field will see new digital bells and whistles as gimmicky. Or worse: these Apps could become distractions or safety hazards.

To be fair, certain features may be tremendously useful for users that repeatedly use that equipment throughout the workday. In addition to usage intensity of the equipment, adoption will be driven by plain old ‘ease of use’. Connected does not equal smart. Smart implies less, not more burden on the user. If equipment can connect itself, transfer data where it’s needed, and do this all on its own without the operators’ intervention, that is far better than asking busy workers to do another task. Part of driving simplicity — if any OEM truly puts the users need for this as paramount — should imply working with other OEMs to explore how cross-OEM data standards and stitching might work. Therein lies the paradox: users for IoT adoption will demand their experience throughout the day to be simple, but behind the scenes this will require OEMs to not only be organized within their own organizational silos, coordinated with skilled tech-savvy vendors, but also potentially communicating and coordinating (within permissible industry regulatory standards) with other OEMs.

The sum of all data, organized differently, stored differently; would at best be data chaos even if theoretically possible to stitch it together from every manufacturer. The number of potential data fields is endless, because there could be countless conceivable reasons to “connect” a piece of construction machinery to its operator, to other machinery, to the jobsite offices, or even back to a rental company or the manufacturer itself for monitoring.

Many new IoT features coming over the next years will likely be “pushed” by manufacturers trying to impress the crowd. The Automakers jumped headstrong into emergency calling tools like OnStar and digital satellite radio well before Consumers pushed back with insisting on connectivity through their own Smartphones. Naturally each manufacturer wishes to cultivate their brand as innovative and tech forward. But in the early chapters of IoT for the jobsite, most machine data will disappear into a digital oblivion; never used to its potential; effectively meaningless. Over time, as more features appear on equipment, the need for systems and standards to collect and synthesize this data will grow. Today, the data are either missing, inaccessible, or incompatible. It’s early days for the Smart Construction site, and we will still live for a while in a primitive period of data chaos. Only the most fearless CIO from a large Construction Group or Rental Company will be staffing teams to weave together some data harmony from across disparate manufacturer systems.

Problem 3: There’s not yet a clear winner like Android serves for smartphones, to play the role of marketplace host, air traffic control, and security guard.

The status-quo is an organic state that follows as hundreds of manufacturers pursue their own ideas and use cases. B2C adoption works very differently than B2B; but the analogy on the game theory faced by each manufacturer remains the same: the winning platform will need to be very good and very dominant. A single maker of wash machines will not be the winning race horse. Complicating the race: the consumers are going to jaded. Will this early period of jobsite experimentation pave the way for progress, or cause push back among confused users?

OEMs who overinvest in new IoT features may see poor financial returns from positioning their own digital standards as important, while underestimating the process change these may require for users or crews, or underestimating the magnitude and power of network effects. While hindsight is 20:20, the shortcomings of Blackberry and Nokia are more widely understood than the competitive dynamics for industrial equipment. The lessons there are transferable and cautionary. Core features from these early leaders of the phone’s evolution into smartness continued to be vital: many Blackberry users found typing emails easiest on their keyboard; and many Nokia users appreciated the clarity of sound quality on calls. Yet both makers clung fiercely to their own App stores as an interface — and continued to do this stubbornly beyond the point when other smartphone App marketplaces were clearly becoming the de facto preference not only for users but also for Software makers many who needed to reach desktop and enterprise users with a new mobile version.

Could an IoT platform provided by a Software maker independent from the OEM, become so powerful and ubiquitous that equipment OEMs would have no choice but to satisfy users with a common standard; as most Smartphones selling into Europe and North America from any brand other than Apple would likely need to offer Android? And exactly what common data might the equipment provide through such a platform?

The folly of electronics manufacturers who tried for years to win over their users with their own proprietary data and workflows as platforms should serve as cautionary. How many Consumers ignore the television manufactures’ own embedded “Smart TV” experience and instead are plugging in their own streaming device from their preferred tech champion? How many automobile drivers ignore (or worse, hate) their car’s built-in embedded “Navigation & Entertainment” experience, preferring to run this directly off their Smartphone?

Consumer preferences work differently than Enterprise ones: but the common thread is choice and flexibility. The typical Construction user exerts far higher autonomy of choice than say a Manufacturing workers or even white collar middle manager forced to use the company’s preferred corporate software. A Construction company or worker unable to justify learning and regularly using over 10 different IoT standards and feature sets will simply brush these aside.

Imagine an outlandish scenario, that a well-known digital maverick came to the rescue.

On January 1, 2020, Elon Musk announced a new company, fused with talents from Tesla and the Boring Company, to deliver “ACE” … Autonomous Construction Equipment … aspiring to capture 50% market share away from the likes of American multinationals like Caterpillar, Terex, and Stanley Black & Decker within 10 years. “To build thousands of functioning tunnels that can alleviate urban traffic for the world’s 100 largest cities, we’ll need far more than boring equipment. Workers using ACE machinery will be 4x more productive, enabling us to profitably pay at least double industry-standard wages.”

Obviously, that’s not a real headline. But is this too far-fetched? Suspend reality for moment: perhaps a maverick entrepreneur, known for big thinking in a world awash in financial capital and filled with city-dwellers crushed daily by soul-sucking-traffic, could truly pull this off.

The leap in efficiency from autonomous, coordinated machinery (e.g. which saves on labor cost; or put differently, enables labor to earn significantly more through achieving far higher output per worker) not only justifies the premium cost for the requisite IoT features, but also obviates the traditional set of functions. Who cares, about faster drilling by a human operator when a machine could drill or cut all night long even at a10% slower rate per minute? What autonomy could accomplish is to disintermediate the engineering performance of equipment “e.g. saw into concrete” from its autonomy, battery-charging, and digital workflow needs.

The advent of a type of ACE would spell bad news for many legacy equipment brands in Europe and North America, as suddenly dozens of previously unheard of brands emerging from Asia might be glad to provide ACE with the core hardware white labeled into which ACE could layer the autonomy, machine learning, and connection points for digital workflows.

The customer is king. And the customer loves a unified, optimized, consistent, reliable experience. That experience for IoT will need to be rooted in a digital platform that fits together seamlessly; not requiring added integration complexity, costs, and managers.

Legacy hardware brands producing equipment used on Construction sites need a clear strategy rooted in the humility to realize their limited authority on becoming the platform of choice before running too far down the path of becoming self-declared IoT champions.

OEMs’ “core business” will remain the internal components and workings of safe, efficient, and easy to use equipment. For digital data not sensitive to those workings, users and their companies will want freedom and flexibility with how they process their data.

Exactly what data from equipment could users find to be openly accessible

The jobsite is a menagerie of equipment types. Across more than 100 categories there are no standards for what the equipment could or should digitally sense, store, and transmit. There are no standards for how this data could be processed. While the fully-IoT connected jobsite may remain 10 years or more from reaching mainstream, some battle lines have emerged along some predictable behaviors, leaving end users lacking.

• OEMs “It’s now a connected device! But, the data works within our own framework; so download our App.”
• Startups “We’re IoT enabled. Our Software will stitch everything together. All you must do, is purchase an after market device, install on every machine, train every operator, and find a local systems integrator to tie-in our system to your digital workflows.”

The sum of data from all equipment could be endless (or often, meaningless). Regardless of equipment type, there are certain factors common. The most common data needs could become a discrete, easy to understand list.

Telematics and Asset Management for Construction machinery is not a new field. There has been a robust ecosystem for at least two decades. Factors that turbocharge the recent change in competitive dynamics, for both of these fields, include:

• A shift from mechanical drives and controls inside machines to fully electric ones (think of your car)
• Lower cost of data sensing and storing (think of Moore’s law)
• Lower cost of data transmission (think of ubiquitous mobile network coverage)
• Miniaturization of sensors and chips (think of your Smartphone)
• A rise in Cloud computing to process data anywhere and potentially automated forwarding of certain data from one system to another

Fleet optimization is an eventual goal of most companies that depend on significant equipment costs. As AWS delivered “uptime” with optimized utilization of servers, a theoretically “perfect” Construction group or rental company could provision the best-suited tool or equipment for the exact best moments of use. Thus users might optimize cost per unit of work, paying only for usage or “Products as a service” rather than purchasing and suffering “total cost of ownership” including transport, maintenance, service records, or even worker training. Many tool and equipment sharing platforms emerge, but all will face the challenge of transaction costs: transportation, and upkeep. Measuring incremental wear and tear is especially difficult.

Many others have speculated what common and open data equipment could transmit. Here is a starting point list, which could support a range of other related digital workflows involved in safety and productivity:

★ Identity. Who am I? E.g. What model number, serial number, software version…?

★ Ownership. Who do I belong to? E.g. Which person, crew, company, jobsite…?

★ Location. Where am I? E.g. Geolocation or even specific indoor spot on the blueprint…?

★ Proximity. What just became near? E.g. Under certain weather conditions, angle of operation, proximity to other people, do I need to pause, stop, or adjust?

★ Users. Who has access to operate me? E.g. A certain person only, any person with a given certification, any users belonging to a company?

★ Status. What’s my maintenance record?

★ Power. How’s my supply, or battery?

★ Instructions. How am I operated? Serviced?

★ Cautions. How can I flag incorrect or unsafe operation to the user?

★ Activity log. What’s been my cumulative use today, this week, month, and year?

Communications standards also matter. A fortunately common feature already across so-called “Smart” equipment on construction and industrial sites is the Bluetooth low energy chip. Thanks to consumer tech, transmission may be simplified. Additional connection types, including LoRa, WiFi, and cellular, also gain adoption for allowing devices to communicate directly with the cloud. Communication standards — not to mention also IoT security as no minor afterthought — are not the focus of this article, but will clearly complicate and slow connected jobsite machinery IoT. An outside tech company like Cisco for helping create multi-connection (e.g. Bluetooth plus WiFi plus LoRa) and secure networks across large sites with difficult ranges (long distances, thick concrete and metal obstacles, underground areas, etc.). Adoption will depend on network routers that work as hubs to collect data from many devices using many connection protocols and connect this to the Cloud.

Data persistence will also require clear standards. Considering who has access for toggling on and off persistence of different data parameters could multiply the complexity whenever the worker, foreman, jobsite manager, company CFO, rental company, and manufacturer all have different sets of interests and timing needs to be accessing and processing data.

Glossing over connection and security standards does not intend to minimize the importance of these subjects. I would contend that if relevant industry players were sharp and bold in depicting their use cases, and a viable platform emerged capable of syncing data across any type of connected hardware, the transmission and security standards will be clearly solvable because other industries such as logistics, utilities, and automotive have already generated huge financial incentives for winning IoT core technologies to both advance in performance and mature in cost-competitiveness.

Each OEM undoubtedly optimizes access and functionality for their own equipment and users. On top of these, major equipment rental groups attempt an integration layer. Rental companies are better positioned and incentivized to automate a single dashboard for visibility and access to data from a heterogeneous mix of equipment than a single OEM. They have a clear incentive to manage this, yet must engage in a nonstop and expensive game of “whack-a-mole” to manage constant changes from manufacturers as well as new manufacturers.

But now imagine the collective Construction group CIO sigh of relief, if all OEMs supplying their equipment signed onto

1. openly sharing data (e.g., not encrypted)
2. clearly harmonizing how that data structured
3. reliably transmitting that data through one or two standards of BLE or LoRa

Risks cloud manufacturers thinking about such simple answers. What if the safety of the digital controls for a backhoe might be compromised by users and companies that wanted to modify these systems. Users cannot make “unauthorized” modifications to these core systems for either their Autos or other heavy types of machinery. The “Right to Repair” debate has simmered in recent years as farm machinery OEMs claim that advanced electronics require certain Software licenses and expertise that exclude users or their unlicensed “shops” from making custom modifications outside the purview of the OEM or its official dealers. Does the story of the vehicle hacked through its entertainment system stir up enough fear to provide no open data link? Security is obviously important. And the dangers of distracted operation must keep the attorneys at Big Tech cautious as those companies’ own navigation, communication, and entertainment systems have become the default preference for an increasing share of drivers. Construction equipment OEMs will not stay outside the debate around “right to repair”.

A compromise could come from segmenting “core” vs. “adjacent” data needs. Certain data users want access to for related digital workflows need not interfere with core operating systems. Yet OEMs tend to ignore or over-complicate the simplicity of such needs. What if OEMs would structure the architecture to sanction certain basic usage data. This “open” set would be intended for one-way flows, thus open for any user or Software API to access. If that one-way data flow had no influence on the power, controls, or computing resources of the core operating system, certain restrictions would be assigned without constraining users access to data and even while equipment was actively in use. Each of the 10 data variables cited above, should be possible for a piece of equipment to sense and transmit for raw added hardware costs of less than $10 per unit.

Rental companies and large contractors advancing their digital transformation would be among the first early adopters; good candidates for investing in this type of premium add-on version of the same equipment but now IoT ready. They look to streamline collection and analysis of data for example capturing time-series of data regarding location, usage activity, maintenance records, and safe operation. In some cases the most motivated of these may be already investing beyond $10 per unit for both after-market hardware and then also suffering complex Software integration costs incurred by their own staff. Reasons for needing the data varied: most link to advancing digital workflows around safety, productivity, and task coordination on the jobsite.

An obvious, holy grail for construction CFOs will be to optimize asset utilization. All major Construction companies recognize that their tools and equipment budget tends to become a big, fat, sometimes undecipherable slush fund also used for other miscellaneous purposes because recording keeping gets messy. Equipment records tend to be poor, except for the highest value equipment or machinery which is legally liable to be kept in safe operating condition. If CFO offices could more easily summarize into dashboards, how long equipment and tools are actually used, which brands of the same equipment empirically get the best runtime between maintenance (controlling for the intensity of use, and controlling maintenance and rental costs), new steps towards better optimization of these large budgets would become possible. Contractors widely agree this ought to be better optimized, yet few would tackle the accounting mess of accurately tracking and optimizing. If every piece of equipment openly broadcast its status, usage, and location; for a gateway to gather and process into whichever cloud software was preferred: such visualization is both technically and operationally feasible.

How might a Software company be best positioned to harmonize the data chaos?

Imagine there was no Android or IoS. Consolidation to few operating systems for Smartphones helped propel adoption of Smartphones to over half the global population. The ongoing early days of IoT remain marked by dozens of potential platforms, protocols, transmission standards, not to mention the dizzying realm of security. Towards a future of ubiquitous connected construction equipment, makers will unlikely reach mainstream beyond the current group of elite 1% motivated CIOs at the Rental companies and large Construction groups with innovation teams until platforms consolidate and standardize. How might this unfold? There are several candidates:

1. A single manufacturer builds a mega platform. That’s unlikely, as described in part 2.
2. A user builds this. That’s also unlikely, with exception of a rental company that has powerful incentives for cracking the code.
3. A Software middleware emerges. This installment explores who could do exactly that. Would it be a startup? Autodesk or Procore Technologies? Or, as spoken in hushed tones on the sidelines of Construction tech conferences: will Google or Amazon suddenly make a splash into Built-tech?

A platform winner emerges from a high-risk, high-reward battle. Who gets to set the standards? Construction and industrial machinery is overdue for IoT digital equipment standards associations. Big auto has setup various safety councils working on ideas such as Vehicle-to-Vehicle (V2V) communications. No clear council exists for big construction machines; though any reader aware of such groups would be welcome to post information.

Platform is also a fuzzy term. There can be various layers of sophistication to pull together disparate parts.

Who are the likely Software middleware candidates to drive this, and disentangle the industry from all data siloed by individual OEMs? What follows are several scenarios.

Scenario: A Construction Tech Software giant sets the pace

Could Autodesk, Procore, or Oracle will figure out a Hardware plug-in (or better said, create blank “input” boxes suggesting a future “click to download” setting), and motivate their users to intensely lobby their favorite hardware brands to play along.

If even the humble light bulb can become “smart”, then so could a basic “hammer” — assuming any user had a purpose for that. There’s little doubting that OEMs for machinery and tools are capable of embedding a <$10 material cost IoT chipset to sense and broadcast data. OEMs sourcing a full-stack and upgradable kit from a solution like Particle IoT could potentially avoid the fits and spasms of every few years upgrading; or of continually aspiring to be the one equipment maker to unite them all. Phones, receivers, and other internet-ready equipment could grab and forward open data to the Cloud. From the Cloud, Software platforms like Autodesk Construction Cloud or Procore IoT data could become like a HUB or “air traffic control” for contractors to route data into its intended useful workflows: for accountants to manage invoices and procurement, or for workers to find tools or receive notifications that tools and machinery on site today do not include what’s needed for tomorrow’s schedule. The many potential workflows are complex and varied. Like the lightbulb maker, imaging every iteration and plugging into all of them, could be maddening.

But for the SW giants to convince the equipment makers to play along — they’ll either need an incentive or a competitive threat to persuade OEMs to broadcast into a reachable location.

Seeing a platform and its value at a current point in time — like Google Android or Apple iOS — is simpler than predicting the factors that led to its rise and will determine how its market evolves over time. Platform plays are difficult; yet powerful and influential if reaching massive scale. In the U.S., Amazon for retail & cloud computing & smart home, Salesforce for CRM, and now Procore for Construction have gained enormous traction thanks in no small part to a type of “open” approach that aims to make it as easy, consistent, and predictable as possible for other systems to integrate. Traditional rules about competition (or in the case of Amazon, potential antitrust challenges) become overwhelming. Consider that to “force” the platforms to “open up” — as Microsoft arguably was several years ago with antitrust action — can paradoxically increase power and control, rather than limit it and open the path for new entrants. Why? Once open, the platform can become a magnet attracting others in the industry to latch on; extending the momentum, reach, and ultimately dominance.

Over a recent coffee with Patric Hellermann, Founding Partner of Foundamental, there was further discussion that inspired finally writing down perspectives about the role of equipment within the emerging Construction tech ecosystem. Also actively meeting many startups aspiring to gain prominence as a type of integration platform for IoT data, Patric has come to a view on 3 preconditions that must be in place.

1) Are they important enough to users in the market?

Only the Software players with significant market share within the relevant Construction segment could credibly call a major equipment OEM and secure a meeting about data plug-in standards. An OEM for civil construction machinery unlikely answers the phone to discuss data plug-ins from a #4 provider of Civil Construction ERP Software provider, Design Modeling SW, or Project Management SW. Keep in mind there is no Construction market, rather an amalgamation of many segments for trade and project specializations.

2) Are they trustworthy as data stewards?

The win-win needs to enhance the user experience, first and foremost. If the Software platform has a less than transparent data strategy to seek secondary advantages, this may not be perceived as a fair quid pro quo. Everyone knows Amazon’s “logistics as a service” fulfillment conveniently gives them access to vital data: e.g. which consumers buy what when. Those data enable Amazon potent insights for if it ever wished to directly supply a competing product perhaps from a private label, or if it wished to sell marketplace ads to competing products. If Construction Software uses equipment data not only to help users keep maintenance up-to-date but to quietly supply market data insights to other potentially competing equipment providers, trust is lost. Preserving security and integrity of data and systems is also important.

3) Is this core to the Software company’s business?

Hardware communicating its status to an ERP Software for purposes of an inventory at year-end would be clearly close to the core business and purpose of that software. The accounting Software probably knows what types of equipment are manually counted today, and perhaps also how many hours of work goes into this manual inventory counting process. That would help them calculate and assess the business case relative to the hours of work potentially involved with setting up data plug-ins. A Software company that’s core is supporting computerized building design for architects and engineers may find it a harder stretch to get into Asset Management. The equipment rental companies clearly find this tech area core to what they do.

I would propose these three motivations are all necessary, and a fourth “FOMO” one may also be relevant: if you don’t, someone else will”.

4) Will someone else? Could this be a gap, leaving an advantage to a competitor?

The threat of competition is powerful. If others advance sooner in a way that leaves the other company “behind” and exposed to its users asking tough questions, a company otherwise disinterested may suddenly become motivated to invest. These competitive dynamics economists like to model with game theory: the outcomes are hard to simulate and individual company actions may not become clear or predictable until the game gets played several times.

Uber’s popularity drew competitors with mobility App alternatives emerging in nearly every global major metro market that did not respond with regulatory hurdles or hostility. Covering taxis was insufficient if the goal was mobility. In the U.S., the rapid rise of Uber and its fast-follower Lyft has led to an escalating race to push further into all mobility services: food delivery, bikes, scooters, and perhaps soon public transportation. Although the makeup of Software types and legacy trajectory within Autodesk, Procore, Nemetschek, Trimble, Oracle, and Bentley Systems is varied and often more different and specialized than they’d seem, at a high-level, the industry-leading Software players are increasingly locked into an arms race to both expand (“close gaps”), to connect workflows (“design to build to operate”), and to make the data plug-ins as interoperable as possible.

Either the economic cycle (Construction companies have a bit more cash to invest and hire), younger computerized generation taking leadership roles, or simply better lightweight mobile Software solutions have lit a fire under industry adoption, with many leaders claiming growth rates in 2018 and 2019 beyond 20%. Though the Construction Software giants may not plug-into hardware today other than Smartphones, out of sheer competitive pressures some linkages into jobsite hardware IoT could emerge.

Judging by trade shows and press releases, advancing interoperability appears to be one of the highest priorities. The range of workflows shifting from paper to digital based have been written about and commented broadly. Outside the industry, observers would be aghast how many regular tasks like recording daily activity logs, labor hours, and inspections are still done using paper based processes. As these finally go digital, users in the field and back office are quickly becoming more imaginative about how hardware could play a role in both simplifying and automating data collection and processes. What if cameras at entry gates could log entry and exit times for workers, inspectors, and deliveries? What if cameras could also monitor regular use of safety gear? … and create a digital twin of daily progress? Except for a few security cameras, or crane-mounted progress cameras, this surge of new cameras didn’t exist until recently on the jobsite. Why stop at cameras — the “new” equipment on the jobsite. Why not continue to plug-in with the “legacy” equipment?

Large Construction Software providers would be leading candidates to harvest and process into further digital workflows a set of open IoT data coming from equipment, including maintenance status, location, safe and correct usage, and more. But other market participants may also take a shot at accomplishing this.

How might an OEM, industry association, or a startup be best positioned to harmonize the data chaos? How would competitive dynamics incentivize (or complicate) this?

The last Part speculated if a leading provider of construction project management software could drive OEM adoption of open IoT data sharing on behalf of the site users who may increasingly demand access. This final part speculates who else could lead the way.

A startup champion emerges.

Buzzwords like “IoT” and “Digital twin” reflect popular themes for startups in Construction Tech. Many startups proclaim to have the biggest answer to tackling these challenges. Startups in IoT will need to either offer Software other equipment makers plug-in with (a tall task, convincing them all to adopt yours), and/or will need to offer a type of after-maker Hardware tag. Imagining a common OEM tag embedded at manufacture would be technically effective yet operationally and strategically difficult to pull off. As it is, most venture capitalists eye hardware with some skepticism as it lacks the ease of massive scalability that software often provides. There is no easily repeatable or massively scalable process for after-market IoT-tagging of every piece of construction machinery, equipment, and tool. Startups ambitiously pursuing this challenge often overstate the degree to which technology is the bottleneck. Usually instead, it’s cost: cost of hardware, but also labor cost of physical execution of tagging and maintenance of these. Startups by size typically cannot help with onsite support except for their lead clients or through partnership with some other major company that offers widespread distribution. Any emerging startup champion would need to smartly consider how to leverage partners to manage tagging, training, and maintenance.

Nonetheless, promising startups emerge. There are dozens of examples. Each tend to take a certain business development angle. CloudLeaf for example takes logistics optimization angle and TrackUnit takes a telematics heavy machinery predictive maintenance angle. While operational implementation will always be a hurdle, one or more of these may break through a define a standard platform onto which many Construction equipment providers will seek native OEM built-in functionality to plug in with. For heavy machinery, SafeAI and Built Robotics illustrate a promising approach at getting machinery to work together collaboratively. An equipment maker might perceive it less risky to work with a vendor-neutral startup than with other equipment makers who may be its competitors.

Scenario: An OEM industry association emerges

Similar to how the Tech giants finally got together to define IP standards with the connected home and continue driving standards, industrial and construction equipment and tools OEMs might discover common ground to work together. Arguably towards protecting their potential profit pools related to data, they should have an incentive to pursue this sooner than later, rather than leaving space for big tech companies to build off their success in the smart home to venture onto the smart jobsite. Two motivating factors also agreeable to most country regulators (policing anti-competitive collaboration) are safety and autonomy. As with earlier examples from the Automotive and Consumer Electronics sector, drawing lessons from others will be instructive. Where could an auto industry style “Detroit test track” be setup for testing machinery at an R&D-oriented, open industry mock construction site environment? Multiple Construction industry market participants would for example likely rally behind a clearer standard between helping machines and people avoid each other, as smart forklifts in logistics centers begin deploying. Talk of future robotic and cobotic solutions shifting from controlled “bolted down” manufacturing and logistics settings to unstructured jobsite environments nearly almost includes consideration of smarter and safer human interfaces. Yet these efforts remain largely within a single OEM; working independently. There are few known industry working groups tackling these standards. (If some are well-known, please cite in the comments!)

Another scenario: users rise to the DIY challenge

Another version of industry association — rather than the OEMs’ own association — might be an association of interested Construction Groups that team up towards defining a vendor neutral set of data formats and standards for interoperability. In other words: all providers have failed you, dear users, so Do it Yourself. The largest Construction Groups have been hiring data scientists and strategy consultants who understand data mining towards exploring what operational efficiency improvements can be identified and supported through analytics of available data. Mining and Energy has greater scale and repeatability to have invested in these competencies for years, but now an increasing number of Construction groups are also building in-house teams. Josh Kanner, a serial entrepreneur and current CEO of smartvid.io, launched last year the Predictive Analytics Strategic Council. The PASC is a recent setup, whose initial members appear motivated to inventory data sets related to jobsite safety (including from equipment?) as a first step towards fleshing out an agenda for needs common across providers.

Safety is a topic that tends to be more regulatory “safe” for either a coalition of OEMs or a coalition of Construction Groups to sit together with competing companies towards defining standards which reduce complication and thus increase adoption. Regulators and users should embrace and encourage such collaboration. Adopted standards could form the core for further IoT standards thereafter.

Concluding thoughts

Equipment manufacturers have a tall list of digital tasks, but are typically so self-interested around their own machines and tools that they fall short of engaging actively with their users to understand how IoT will need to work across a menagerie of equipment. Rather than throwing up their hands and declaring the users’ perspective too complex, the best OEMs would do well to map the most common workflows surrounding their equipment. Rather than building interoperability with each set of Software a user might foreseeably like to ingest IoT data, the OEM could consider the list of top 10 data factors above and find a starting point for an open set of 1, 2, 5, 10 data variables that it allows to become perfectly open for the users to capture using phones, routers, or other off the shelf equipment. That’s not casting data into the wind; that’s working with lead users on a type pilot or experiment towards learning how many users would easily pay the added $10 material cost for a piece of equipment that never more gets lost (remember, one time it’s lost or falls into disrepair, may already burn well over $10 in lost productivity). Expecting users to solely use the OEMs’ own SW app for receiving such data will unlikely win the heart of users.

Regular users of construction equipment — whether the end user worker, foremen, managers, or CIOs — will be making the trek to ConExpo in 2020. Certainly, they will see a dizzying array of new Bluetooth (or other) connectivity feature sets and Apps. Rather than getting lost, or hyped by these features, one of the best questions users might ask is “how easy will it be, to get access to my own data”.

How could a Smart hammer fit into the increasingly digitized jobsite ecosystem? Factories of 2030 will embrace “Industry 4.0” — digitizing everything and visualizing end-to-end workflows with computer models to seek and execute improvement areas. Construction Sites of 2040 will inevitably see clearer orchestration that significantly minimizes waste not only of precious labor and environmental resource taxing waste of residual materials, but also waste in terms of poorly utilized or maintained equipment. Yet today, almost no Contractor would have data to show which brand of equipment was most cost competitive not in purchase price but in operating run time.

Top Construction groups have already begun down the path of experimentation; at times, more so than equipment OEMs realize. As sensors and communication chips become dirt cheap, digital equipment down to the hammer is not absurd, it’s inevitable. End users may not care for now, but their back office, foreman, and project superintendents will start getting some interesting benefits once these pieces tie together. Wasting 20 minutes searching for an asset or piece of machinery, fully-allocated, will already surpass the added hardware cost for an IoT sensor stack.

OEMs need to reflect on this transition period. The adoption curve of leading, interconnected solutions like Procore and Autodesk Construction Cloud may become a more important proxy for user readiness than the number of App downloads for that OEMs own device management software. Reflection should also span other industries; Construction is not the first to connect the hardware into workflows. While Industry 4.0 in Manufacturing may seem closer relevant as a B2B, safety- and productivity-relevant analog more so than the Smart Home, the ease of use and end-user sensation of benefit (“what’s in it for me”) around Construction IoT may require closer thinking towards SmartHome analogs.

One clear lesson must be taken: not all Smart features are the same. OEMs are right to carefully protect and guard their investments into sensing and optimizing internal component performance of their own machines. The user doesn’t need gory detail from such core data; rather simple metrics like “service soon” or “incorrect usage” . For very basic data parameters like run time and location, less sensitive, OEMs could consider splitting these out and broadcasting them openly. As many jobsite operations switch from paper to tablet, the likelihood and value of Construction sites grabbing and processing this data to track and orchestrate productivity will increase. Chances are, the urge for keeping non-core data “open” will be high.

It remains to be seen who can best access and harmonize that data into newer platforms; but within the coming 2 to 5 years, I predict that leaders will become easier to spot. Manufacturers would be smart to engage actively and collaboratively within the tech ecosystem with a culture of experimentation, to keep the options open and the learning exposure high for internal product managers. Rapidly growing Construction Tech forums are more than hype and marketing: they’ve become increasingly open forums for users to share tangible experience from testing new technologies. This will only accelerate the pace of adoption, giving the unprepared OEM even less time to react and adapt should they go so far down the commitment path in the style of their own Nokia Symbian or Blackberry that reversing course to embrace an industry standard Android or Apple iOS becomes incompatible. Experimenting with openly broadcast data parameters, whether with Software companies, other OEMs, or startups — is not risky, but vital. OEMs that ignore this and presume their users will embrace closed, proprietary systems could be undertaking the riskiest of all ventures.

Gregg Wallace is the Director of Hilti’s Outside-in Tech office in San Francisco. IoT is one of several themes that Hilti’s global outside-in team regularly explores while meeting startups. The views expressed are the author’s own. For more on Hilti’s Outside-in team, visit https://www.hilti.com/content/hilti/W1/US/en/company/about-hilti/construction-technology-ventures.html