An interview about #Erlang and embedded devices with Omer Kilic (@OmerK)

Hello there! Today you may read my interview to Omer Kilic, a very famous guy you may know if interested in Erlang and Embedded Electronic Systems. 

I think you will find his answers very inspiring….it is time to get a Raspberry PI!

Code some Erlang while you are having some raspberries!

 

Paolo – Hi Omer! Thank you for making yourself available for one of my interviews. Would you like to tell our readers something about you?

Sure, I’m an Embedded Systems Engineer currently working on Erlang Embedded, a Knowledge Transfer Partnership between Erlang Solutions and University of Kent. The aim of this KTP project is to bring the benefits of concurrent systems development using Erlang to the field of embedded systems; through investigation, analysis, software development and evaluation.

Paolo – Why should we want to have Erlang on embedded devices?

Erlang has features that are highly relevant to solving problems we face today with modern embedded systems such as dealing with connectivity, distribution and concurrency. We also have a different take on error recovery and supervision hierarchies which reduces the overall complexity of the system and leads to less code being written, which in turn increases testability.

These features make Erlang a suitable tool to use as the orchestrator and the systems language of these complex embedded applications we are developing for the future.

While Erlang is currently being used for very large scale distributed applications, it has roots in Embedded Systems. It was originally conceived to deal with the issues, such as the fault-tolerance, concurrency and the distributed nature of telephony hardware at Ericsson.

Paolo – What are the devices that currently can run Erlang?

The rule of thumb is: if you can run Linux on your device you should be able to run Erlang on it too. This covers most of the current ARM and MIPS based platforms. There have been ports to other operating systems, such as VxWorks, in the past as well. We currently don’t support a ‘bare-metal’ setup.

The VM doesn’t actually require a lot of resources to run (this obviously is application dependent) and you can slim down the size of the installation using the packaging tools included, which will create a tailored distribution that will only contain the runtime system, required libraries and your application.

We have chosen Raspberry Pi as our reference platform and we provide packages for the Raspbian distribution so you can get started with Erlang quite easily if you have a Raspberry Pi board. We will also be releasing packages for other distributions and platform in the near future.

Paolo – Why did you choose Raspberry PI and not one among the other famous platforms (e.g. Beagle Board)?

Raspberry Pi is an exciting project with a very enthusiastic community around it. I think they have successfully removed the hurdles in getting started with Embedded Linux by providing an affordable, simple and well documented hardware platform with a thriving hardware and software development body attached to it.

Another reason why we chose the Pi is the educational side of it. If we can introduce concurrency/parallelism into the ICT curriculum, young people will learn about these computer science concepts way before they start their further education.

Paolo – I think Raspberry PI is very good for learning, but do you think it is mature enough for industrial purposes?

We see it as a great educational tool but also acknowledge that it may not be the best platform to integrate into industrial applications. As such, we work with other Embedded platforms such as Beagleboard and Gumstix for commercial applications.

With the layered hardware abstraction model that we are working on at the moment, the platform choice doesn’t really change the way you architect your system. Learning/prototyping on the Pi and deploying it to another platform is perfectly viable as long as the low level drivers are in place.

Paolo – Was it difficult to port Erlang on Raspberry PI? Did you change some stuff related to the VM?

Other than a few minor fixes it wasn’t difficult at all, in the end we actually ditched our cross-compilation setup and compiled natively on the Pi itself!

Paolo – Most of the video published on you tube are simple examples of applications which turn on/off a led or exchange Erlang messages. Are you actually working on something more complex? And if so can you tell us something about it?

We wanted some simple examples for those videos as gentle introductions to some of the features of Erlang.

Our current project is the hardware abstraction library that I’ve mentioned previously, which maps hardware to the Erlang domain doing some interesting transformations along the way to facilitate concurrency. We will be releasing the first version of our library in the coming weeks.

Paolo – I believe you are not controlling the sensors connected to Raspberry PI with Erlang. Am I wrong? How do you deal with this? Maybe with a C port?

We are controlling the sensors using the peripherals on the Raspberry Pi, using a collection of NIFs and ports.

Most digital sensors can be controlled by the Pi as it has peripherals such as SPI and I2C to deal with the interfacing, analog sensors require some additional circuitry though as the Pi does not have an Analog-to-Digital converter.

We abstract away the lowest level functionality into C ‘drivers’ and interface them to the Erlang domain using ports and NIFs. These facilities are documented in the Interoperability User’s Guide.

Paolo – Nowadays, smart grids and smart buildings are on everyone’s lips. Both are related to distributed systems where efficiency, reliability and low power consumption are features needed. Do you think Erlang could help in this sense?

Certainly, we see Erlang as a highly relevant tool to tackle these challenges.

The Actor model of concurrency we have in Erlang lends itself well to distributed systems. The runtime is fully network aware and passing messages between different physical nodes is as simple as local message passing.

The OTP framework has battle-tested supervision hierarchies that can be employed to deal with error recovery/containment and provide high reliability. Quoting Joe Armstrong, the father of Erlang:

The Erlang flagship project (built by Ericsson, the Swedish telecoms company) is the AXD301. This has over 2 million lines of Erlang.

The AXD301 has achieved a NINE nines reliability (yes, you read that right, 99.9999999%). Let’s put this in context: 5 nines is reckoned to be good (5.2 minutes of downtime/year). 7 nines almost unachievable … but we did 9.

Power efficiency is an area we haven’t looked at yet but it is definitely on our very exciting list of future explorations.

Paolo – How can we know more about Erlang embedded? Is there any technical document or blog about it?

More information about the Erlang Embedded project can be found on our blog and you can also follow us on the @ErlangEmbedded twitter account. Please feel free to get in touch if you have any specific questions!