1. We are here at TechMesh 2012 in London, I’m sitting here with Omer Kilic, so who are you?
Hi, my name is Omer I’m an Embedded Systems Engineer at Erlang Solutions, I’m part of the Erlang Embedded Project which is actually a joint project, a knowledge transfer project between Erlang Solutions and the University of Kent. We are evaluating and looking at Erlang as a tool to replace the current tool chains that we use in Embedded Systems. Embedded Systems are becoming more and more complex and there are certain aspects of these devices or these systems that is quite difficult to manage with the current methodologies and tool chains that we have, so we think Erlang has some very relevant and very interesting properties that map really well to this domain and as part of this project we are exploring how to tackle these challenges, such as how to manage concurrency sensibly, how to create distributed systems, how to create fault tolerant systems.
And Erlang was designed originally for Embedded Systems at Ericsson, so they have been tackling these issues for a quite some time, so we're just trying to create some nice methodologies, etc, to map to these little devices that we work with. So traditionally, I mean while it was invented for these very large embedded systems in fact, today Erlang is used for massively scalable distributed web applications and databases and so on, so I guess we are trying to bring it back into small devices managing the concurrency in these devices and creating fault tolerance and supervision hierarchies, etc, stuff that we already have in Erlang and map these to the modern devices, modern embedded devices that we have today.
I think replace is not the word, I should have chosen a better word, so C is not going away, we are fully aware of that and C is actually quite relevant to certain things like writing device drivers and creating very low level modules within your system, but writing concurrent C code or raw socket programming in C, these are that sort of stuff that is not really fun to do. Let alone the fun said, it’s not very practical to do as well, they require quite a bit of effort and you end up employing different frameworks, etc, to tie everything together anyway. We are looking at using Erlang as the orchestrator for these complex systems. Still have a bit of C for managing hardware but we have facilities that let us use these external bodies of C code within Erlang anyway, so use higher level tool such as Erlang to deal with the higher level complexities such as distributedness, communication, concurrency, fault tolerance, supervision, etc, and still keep your C drivers to talk to low level hardware. That is the approach that we are taking at the moment, and as I’ve mentioned Erlang does have these high level constructs or features in place, so we just need to, I guess make it more appealing to the embedded engineers, that is why we are trying to create use cases, example applications and so on.
If you look at sensor networks for instance, you can have hundreds, thousands of these little nodes scattered around a geographical area over different links, different networks maybe, and you need a way to orchestrate the operation of these individual nodes or mesh nodes maybe, connected in a mesh. So we are going through this phase shift in the designs of embedded systems, so everything is becoming connected, everything is becoming distributed and there are predictions by people in the know, like Ericsson, that we certainly will be heading towards a massively connected future.
Look at the change that went through with mobile phones, everyone now has data anywhere they go pretty much, so this whole internet connected fridges, etc, it’s happening and not just that but we are seeing more and more interesting applications that do have connectivity and distributedness, etc, as one of their main design criteria. It’s funny because we see this term 'Internet of things' everywhere which practically means connected systems; unfortunately it’s a blanket term which can mean anything and everything like Cloud maybe. I saw a really interesting example of this, not just tablets or phones or things anymore. A Dutch company I believe, they are implanting sensors on cattle, so we are heading towards not this Internet of things anymore but Internet of cows, or Internet of cattle, it’s everywhere. If you think about it, they are just a little embedded systems or sensors nodes that send data back and you have to collect them etc, so I think we are going to see more and more interesting applications coming out that do have these criteria in the future.
No, I hope not, I believe they just send bio feedback so if one of your animals is sick or pregnant then if you think of a massive cattle ground scatted across the……
5. They are active? They are not just RFID?
I think they are active, they do use RFID technology there but I think they are active sensors
Erlang uses the actor model of concurrency. It’s a very simple model, it’s been around for a while and the basic idea is that you compose your system using actors, in the Erlang World we call them Erlang processes, which are self-contained atomic units that contain some functionality and the way you communicate between them is by asynchronous message passing. So cars and sort of industrial equipment, that is a sort of different use case, because you need certain safety guaranties etc. So if you just ran pure Erlang on these devices, to use message passing, then you might be violating certain things but we are exploring CAN or OBD bus protocols, we are investigating how we can create almost like a transaction system where you have these actors connected via these automotive and industrial protocols that do satisfy these requirements.
The idea behind utilising actors as hardware control blocks is that you can model your system using something along the lines of a black box design methodology that we have in the electronics engineering world, so you can represent each part of your system as an Erlang process and then use the supervision hierarchies to create a layered safety model for these components as well. So your subsystem of your car can be actually a collection of Erlang processes with its own supervision hierarchy that gives you the security and safety, more safety I guess, aspects of these applications. We are doing some experiments with that sort of structure or layering your subsystems into supervisors, sort of proxies and actual hardware drivers etc, at the moment. We use Raspberry Pi and we will be releasing some example, use cases in the very near future.
Yes, the bits of C code that we employ is just the lowest level sort of register manipulation or talking to kernel modules, nothing more than that. The orchestration or the actual sensible logic behind it is all written in Erlang, so for some of these devices you don’t actually need C code at all actually. Another example from the Raspberry Pi, the GPIO Module, if you use the GPIO Kernel Module it’s controlled by a sysfs which essentially is virtual files that you can write on the /sys in Linux. So I have written a full Erlang module to control the GPIO pins, so that was the first or the lowest layer of our architecture I guess and on top of that I wrote a little proxy unit to prevent certain dangerous operations like releasing a pin while another process is writing to it.
So we created this proxy because concurrent hardware access can potentially be very dangerous. I guess you can argue that this is replacing locks in a traditional design sense of embedded systems but not quite because you can do a lot more than just creating a mutual exclusion architecture, a mutual exclusion feature using these. So another interesting thing that I’m looking at, again security is quite an important aspect of embedded system design, so we are investigating whether we can implement certain checks within these proxies, like detecting toggling rates for pins, if it’s above a certain range then we might deem it dangerous and actually either slow it down or generate an error condition to be handled by supervisors etc, or sequence it actually. You may not want to send a certain sequence of bytes or some data to an external node using the I2C protocol or something along the lines of that, so they are clever mutual exclusion plus safety supervisors.
In a way yes, so we are not actually using Erlang directly as just a programming language, we are using it as a systems language, and you are right, it has quite few similarities with microkernel architecture. Another thing that I should have mentioned this before actually, so in embedded systems you generally employ a real-time operating system because it does give you a certain sort of task structure and some communication primitives etc. So people who do design RTOSes when they switch over to Linux, those concepts are not mapped directly to Linux, I mean of course you can use operating systems threads etc, but you have to write it in a language and then tie it together etc. But I think there is an interesting almost similar or almost the same mapping between the RTOS world and the Erlang world, so tasks are Erlang processes, messaging is built into the system, you don’t have to create your own messaging architecture etc, and that model that we use in Erlang is really good because one exploration that we are doing is mapping hardware interrupts and creating Interrupts Service Routines etc, that run concurrently and so on.
There are obviously cases that might be an issue but then you can implement your own synchronization mechanism etc, quite easily. So to answer your original question, yes we are using Erlang almost as a mini operating system and using it as a systems language to structure these complex devices.
Why not? So Raspberry Pi is an exciting platform, it’s exciting for many reasons but it’s brought back the joy of playing with tiny computers back into our lives I think. It’s a very affordable platform, it’s a quite ubiquitous platform, you see a great developer community around it, and they have generated some extremely positive buzz around embedded Linux world and computing, programming. And we see that it’s becoming very popular with kids, young people, who will potentially become future hackers and programmers and architects etc, so we are interested in developing some engaging material for young people to explore concurrency and parallelism and also functional programming using Erlang and to support this we are developing material for the Raspberry Pi including our little demo board Hardware to accompany our little experiments.
We will certainly be talking to teachers and the Raspberry Pi Foundation to see if we can get this into the curriculum, because concurrency and parallelism are issues that we are going to, well we are dealing with it right now, but it’s going to be even more relevant in the future. When young people continue their education or when they start taking up jobs etc, if they are familiar with these concepts and again functional programming as well, we think that will be best for the greater good really. We also use it as a reference platform for our education and outreach efforts as well because, as I said, it’s becoming quite a ubiquitous platform and there is a very positive community around it, people are interested in playing with this.
Again we want to show people that you can do concurrent programming quite easily on the Pi and playing with an interesting new language that might save you from hair loss and headaches in your actual commercial projects as well. We have a blog, http://erlang-embedded.com/ where you can find more information about these things. We are quite excited about this because I think we already have incredible projects done on the Raspberry Pi and we are only going to see more and more of these coming up, so to be part of this community and to support people who are developing all these cool applications, we are quite pleased to be part of that.
You can already have Erlang on your Raspberry Pi, we do provide packages compiled for the Raspbian distribution, and very soon we will be releasing our hardware abstraction library as well so you can control all the peripherals GPIO, PWM, I2C, protocols and peripherals from within Erlang as well, and we are trying to create an Erlang or a model suitable for the Erlang world and still utilize these peripherals. As I’ve mentioned, we’re mapping interrupts as Erlang process messages or Erlang messages for instance, so you can instead of having to poll an interrupt pin or something like that, when that condition happens, we receive a message back and then we can handle it using our Interrupt Service Routine process and so on.
So we are quite close to finishing it, we’ve been working on it for a while and we would love to see some cool and interesting applications with that. I should mention, it’s not just about the cool factor, obviously that is when you are trying to engage with community of hackers that you do go for that, but at the same time we strongly believe that these are extremely useful in commercial applications and dealing with the complexities of modern system on chip devices as well. Sometimes I get comments like: “You wrote some functional code to blink an LED”, well yes but at the same time the concept that we use there is quite relevant to tackling more and more complex challenges as well. Once you are used to blink a few LEDs and then tackle challenges like having multiple sensors and different buses and use the same sort of process architecture obviously with different functionality, but you can architect your system because you know how processes work, how message passing works and so on.
So these are just fun little examples to show you the power of Erlang which be hoped that you will take and apply to your actual commercial applications.
Werner: Well I think we have enough to look at, everybody in the audience get your Raspberry Pi or 4 or 5 for you or your kids, and thank you very much!
Omer: Thank you very much!