MediaTek is making IoT hardware easier to use


Check out the new MediaTek LinkIt™ Development Platform for RTOS. This platform is the first from MediaTek delivering a common toolset and application programming interface (API) for multiple chipsets, including MT7687 and MT2523. It offers developers the ability to create a range of IoT devices using one common SDK with support for professional-grade IDEs (Keil µVision and IAR Embedded Workbench) as well as use of command-line tools.

The first hardware development kit (HDK) for the new platform was made available this summer, the LinkIt 7687 HDK, developed by Silicon Application Corp. (SAC). The HDK is based on the MediaTek MT7687F Wi-Fi system on a chip (SOC), and supports developers looking to create advanced connected appliances, home and office automation devices, smart gadgets and other IoT innovations with secure Wi-Fi. The second development kit for the platform, LinkIt 2523 HDK by SAC, is based on the MT2523G chip which enables you to create Bluetooth-enabled wearables with small footprint, fast and accurate positioning at low power consumption, and high-quality audio playback.

The initiative to work closely IoT developers has proved successful with a number of developers using MediaTek solutions to move from prototypes to successful commercial products.  Now, many enterprises are replicating the MediaTek method of running a similar “labs” program to better learn from developers. But as MediaTek managed to get ahead of the curve, they appear to have the advantage when it comes to connecting their customers with supply chain partners to manufacture and drive success for their IoT devices.




Surprising result from Dresner Advisory on Govt interest in IoT

Some interesting insights from  Dresner Advisory Services’ 2016 The Internet of Things and Business Intelligence Market Study published last month.

It is very surprising to see State and local government reporting “IoT is not important” in 70% of the respondents. This doesn’t seem to correlate with the interest in SmartCity projects – much of which is dependent on IoT solutions.

There are obviously some who see it as critical (10%) and thankfully the City of Melbourne is amongst this group.  According to Michelle Fitzgerald, Chief Digital Officer and SmartCities Office @ City of Melbourne at Startupbootcamp’s IoT and Data FastTrack in Melbourne, “IoT is a critical component in making our city smarter and more livable.” Whilst Michelle emphasises the human side of the City experience, she is excited about IoT and Data (and particularly Open Data) is going to transform our experiences in the City.  She gave the example of how Melbourne’s parking data will soon be available in real-time for startups and businesses to use.


IoT and Data Tech FastTrack Melbourne

We had a great day today at Startupbootcamps IoT and Data FastTrack program in Melbourne, to select a team to attend the IOT program in Barcelona.

Congratulations to all 9 teams that pitched on the day.

Highlights of the day included:

Ordital – crowd sourced asset management. Working with big resources companies and looking to scale.  Voted by all the mentors as the company most likely to succeed.
MStar – personal safety device.   New startup with a personal safety device to deter family violence . Great SME’s and very passionate. Watch this space for news on these awesome gals who really know their space.
Eleso with EMMA – unleashing the power of knowledge. An interesting metadata management and discovery solution. Working with Government and looking to Pharmaceuticals.  Interesting tech and some good early market traction.
Liive – a crowdsource app to share live experience at venues – “try before you buy experiences”  Great pitch and a really good idea that will hopefully spread virally.
The winner was Christina Chen from Second Sight!
Second Sight are providing the in-game analytics platform that provides user insights and emotional intelligence based on user interactions.  I think this has plenty of non-gaming applications in addition to the primary market that they have identified – the indie gaming market.  Great pitch and founder!.

Me and Rich.jpeg

Made up stuff on potential security vulnerabilities of IOT to promote products?

Reading another article about how “theoretically” IoT devices can be used to create havoc on the internet and bring down society as we know it!

Your next DDoS attack, brought to you courtesy of the IoT

iot-securityScary hey … but largely rubbish if you read the articles. Semantics are just trying to scare people into buying their software. the article provides no real evidence of IoT being responsbile for the DDoS attaches and the example they give are not even IoT devices.

“Just this month the security vendor Sucuri reported on a large DDoS attack launched from 3 different types of botnets (CCTV botnet, home router botnet and compromised web servers). While not commonly seen in the past, attacks originating from multiple IoT platforms simultaneously may be seen more often in the future, as the amount of the embedded devices connected to the Internet rises.”

KerbsonSecurity try to relate their DDoS attack to IoT to get publicity with this very weak link to IoT.

“There are some indications that this attack was launched with the help of a botnet that has enslaved a large number of hacked so-called “Internet of Things,” (IoT) devices — routers, IP cameras and digital video recorders (DVRs) that are exposed to the Internet and protected with weak or hard-coded passwords.”

I am not sure when routers, IP cameras and DVRs became IoT devices? Aside from the “some indications”  .. yeah, what indications?  Can’t see any cause and effect in this statement.


Now, I am certainly not saying that security is not important for IoT – nobody wants someone hacking into their autonomous car or flashing the cities smart street lights in time with their favourite song … but these alarmist, self-serving, articles do nothing but confuse the general public and trivialise  the real job of properly securing IoT devices, networks and platforms.

If you are interested in reading something useful on the topic, start with w  which provides some good practical considerations for those building IoT solutions.


New Arduino for IOT hardware hackers


Back in the old days hardware manufacturers felt safe in the knowledge that no mere hardware hacker could attempt to recreate their inventions. From Sony to Philips to LG to Samsung, the consumer electronics industry was locked up and no one could crack the case. Until those meddling Arduino kids came along…

Now anyone can make cool hardware and, thanks to Arduino, it is easier than ever to connect your devices to the Internet and take in data from the outside world. The ESLOV IoT Invention Kit is an official Arduino product that adds Internet of Things capabilities to your hardware products. Trying to build a connected fridge to beat Samsung? Go for it with the ESLOV. Want to knock Sony off its perch? Try popping an ESLOV unit onto your Arduino board and take on major manufacturers from your living room.

Think of the ESLOV system as a sort of Mindstorms on steroids. This self-described “plug-and-play toolkit” lets you connect multiple sensors and outputs together to create various systems. This chart shows a few of the possible permutations. Everything is controlled via Arduino’s online IDE.


Understanding the IOT Landscape: the Middleware and API’s

A somewhatstandard IoT middleware stack will remain a work in progress.

Middleware will play a part as the connectivity layer for sensors in the IOT landscape and but also as the connectivity layer between application layers in the IoT stack. Many writers confuse platforms and middleware, or in effect consider a wide definition of middleware that includes all software between the device and the application as the middleware.  This broader definition is not really that useful in the architectural context, as it confuses the functionality required to be delivered by each of these layers, which are very distinct. I will cover IoT platforms separately in my next article. In my earlier blog showing a Simplified Architecture for IoT I have shown middleware as the layer above the network only, but of course in reality it pervades the whole of the IoT solution.

6031353822_90c2a8e028_bMiddleware for IoT is required for various reasons. The summary of reasons is as follows:

  • Difficult to define and enforce a common standard among all the diverse devices belonging to diverse domain in IoT.
  • Middleware acts as a bond joining the heterogeneous components together.
  • Applications of diverse domains demand abstraction /adaptation layer.
  • Middleware provides API (application programming interfacing) for physical layer communications, and required services to the applications, hiding all the details of diversity. [1]

It is important to note, that enterprise customers will use a combination of existing middleware alongside emerging IoT and M2M integration approaches for meeting the requirements of their IoT projects. The lack of common vendor and platform-agnostic connectivity standards will slow wider IoT adoption, especially from the perspective of enterprise IoT initiatives of reasonable scale, as the grable with vertical IoT solutions and platforms that do not easily integrate.

Typically enterprise customers will not need to care about the middleware used to connect the sensor devices, unless they are building solutions from the ground up.  Typically enterprise customers will be buyings solutions that include the sensors, the network and the middleware to deliver the data to their platform of choice. The key to success is to ensure that the services and data are accessible to your existing enterprise middleware via API’s

It is also easy to get confused as to where API’s fit in the IoT landscape. According to Mulesoft

APIs are enabling interconnectivity in places you wouldn’t imagine. From kitchen appliances to cars, the “Internet of Things” has become a reality. [2]

API’s are a neat way to address IoT devices and the services that they create, but they don’t in themselves create IoT or even enable the connectivity.  In terms of IoT, API’s provide the following key features:

  • Device registration
  • Exposing devices as APIs
  • Applying API management best practises to manage device APIs.

Ensuring that the IoT solution is addressable via API’s is critical.  Implementing IoT systems that are closed and only offer data via the vendor’s provided applications should be avoided. Use of a good open source enterprise middleware solution from Mulesoft, WSO2, RedHat is probably the best choice for your IoT solutions, ensuring that the middleware platform provides a full range of functionality from API management, through to basic messaging, routing and transformation functionality.

MachineShop has long known that middleware – and importantly a new approach to middleware – is a key element in driving IoT growth. [3]

Being the only IoT platform that takes an API-first approach, MachineShop enables all processes to be expressed as discrete services without the limitations of a proprietary platform. The true distinction is that MachineShop is a Platform of Services as opposed to a Platform as a Service. This unique approach transforms the way enterprises and developers build, integrate and manage solutions
to unlock business value and intelligence.

If you thinking of building an IoT solution from the ground up, then the middleware used to connect your sensors is of critical importance. Aside from the basic task of getting reading the information from your sensor network, you will need to be concerned with interoperability, management, scalability, security and privacy.  These issues are discussed below [3]:


This is the classic function of middleware, providing the basic connectivity between physical devices, to data-link to network, transport, session and sometimes application layer of TCP/IP stack. This function also deals with the format and structure of the encoding of the information exchanged among things.

IoT-middleware exposes multiple APIs to perform these interoperation functionalities. SOA-based architecture Ubiquitous Service-Discovery Service are some of the common approaches adopted.

Context detection

IoT-middleware must be context aware for working into smart environments. Context awareness can be achieved by context detection and context processing. Context detection collects data and identifies the factors that have significant impacts on the response. Context processing extracts the context data, processes it and performs or takes decision based
on that.

The middleware performs context detection by collecting information from the sensor devices and extracts required context data by utilizing available data mining algorithms.

Device discovery and management

Device discovery and management enables any device in the IoT network to detect all its neighboring devices and make its presence known to each neighbor in the network. Device ontology is used for storing information about the heterogeneous devices.
From IoT perspective, these modules need to be reliable, fault-tolerant, adaptive and optimized for resource consumption.

Security and privacy11484777313_faf91f9ca7_z

Security and privacy are responsible for confidentiality, authenticity, and nonrepudiation. There has been much written about security and IoT and that many middleware vendors have not implemented security as a fundamental part of their middleware architecture. Implementing security as an after thought could have serious implications for the robustness and safety of the solution and may limit its use in certain industries such as health, finance and critical infrastructure

Managing data volume

Managing data volumes is an integral part of IoT-middleware. It is believed that there will be trillions of objects which will be part of this enormous network and Zettabytes will be stored or exchanged among the objects. In other words the explosion of the amount of data collected and exchanged is beyond what current 11711725656_fbe0919b55_benterprise middleware can cope with. Solutions such as CR-X are addressing these problems. Therefore it is imperative to get novel methods to find, fetch, and transfer data.

Some of the projects that are developing device level middleware include Linksmart, UBIWARE, UBIROAD and SMEPP., SOCRADES,, GSN, ASPIRE,  SIRENA

Not all of these projects fully support the requirements of middleware for sensor networks, and standards are still evolving in this space.  Although much of the research has been done in the last decade, commercial winners have not yet emerged and innovation is still underway. Standards will follow once the innovation cycle slows.

In my next post will explore the platform level, many of which incorporate commercial implementations of the middleware required build a sensor network from the bottom up.


1 & 4  A Survey of Middleware for Internet of Things, Soma Bandyopadhyay, Munmun Sengupta, Souvik Maiti, and Subhajit Dutta