Leading The Way For Safety Certified Rust: A Conversation With Espen Albrektsen Of Sonair

Drew: I did a bunch of research about Sonair before, and I was learning about your ultrasonic sensor, which is called ADAR. Obviously, in robotics, there's a bunch of different sensors that a person could use. Could you tell me how ADAR stands out from some of the normal things like cameras, LiDAR or even other ultrasonic sensors?

Espen: It is an ultrasonic sensor, so it uses sound in air to get a feeling of what's around it. It's exactly the same physics as the parking sensors that we have in our cars. You send out a sound wave and it comes back. The big difference is that our sensor not only gets the distance like your car sensor, it also gets the direction. We send a wave that propagates out as a spherical wave into the air, and then it comes back. Then, from every object that has a reflection, we get some back. That allows us to say where things are. So that gives us a 3D footprint of the area around us.

Espen: The big benefit for light is that it's a million times faster than sound. But, light gets reflected and goes through shiny objects or glass. So, there are some things that are invisible to light. Also, 3D light is pretty hard. Cameras are doing a phenomenal job especially now combined with AI. It's impressive what they can do. But, so far they are not safety-certified. There's currently no easy path forward to safety-certify an AI-driven algorithm for cameras.

Espen: So, 2D LiDAR is the de facto standard for safety-certified robots, and it’s fantastic except that it can only see one slice of the world. LiDAR is a rotating laser that goes around and sees everything that's in its path, but if you're one inch above or one inch below it then you're invisible. That's sort of where the big difference is between LiDAR and ADAR. We have true 3D safety coverage, 180 by 180 degrees field of view. There are 3D safety lidars, but they are quite large and very expensive. And, they don't offer the same field of view as we do. So, that's sort of the main difference there.

Espen: In your iPhone, you also have a LiDAR sensor, and that one doesn’t have any moving parts. For the safety LiDAR, there is a rotating part. For us, there are no moving parts, except the membrane that is part of the microphone and the sound. There are fewer moving parts, so we expect to have higher reliability and lower maintenance. And, it's all software-driven. One of the things that really sets us apart is that we have very advanced algorithms that do analysis of reflected sound. Your environment, as you see it with your eyes, has a lot of information, but your environment as seen with your ears has a lot less information. It’s mostly just air, right? So, we get a fairly sparse point cloud. From a safety perspective, that can be a really good thing. It means there's not so much clutter to remove.

Drew: There are so many things in there that sparked my curiosity. When you speak about these AI-driven algorithms with cameras, does that mean that your algorithms are totally deterministic?

Espen: Yes, they're deterministic. We're pretty sure that there's a lot of cool stuff we could have done with AI, but we knew from the start that safety certification was a very strong selling point, if not a hard requirement. The more we've learned about the industry, the more we're feeling like the safety certification is a hard requirement. Some customers say it's interesting without certification, but most say it would be really great if it's certified. In other words, the two main reasons why we never really investigated much on the AI path are that we can do the analysis deterministically, and we must do it deterministically because of certification.

Drew: You also talked about how there are much fewer moving parts than a lot of other sensors. Does that make ADAR cheaper to manufacture?

Espen: We think so.

Drew: That could be a huge advantage as well.

Espen: Yes, we do believe that we can compete both on performance and price of the sensor.

Drew: Sonair is a pretty new company but looks to be growing quite well. At this early stage, what are the obvious use cases that you're seeing for the ADAR technology?

Espen: As a startup, we had to focus our energy towards some specific applications, and what we are targeting right now is autonomous mobile robots (AMR), because it's a large and growing market. As an example: Just this summer, Amazon announced that they have one million AMRs running in their warehouses worldwide. Our primary focus right now is our sensor as a safety mechanism on those robots. But, in principle, it can be used for a lot of things. It sends out a sound wave, and it tells you where, how far away, and in what direction something is. For AMR our sensor will be on the robot. For stationary robots (moving arms etc), our sensor could be outside the robot. This opens up the cobot (collaborative robot) market and stuff like that, especially in cars. There are a lot of use cases, but our primary initial market is autonomous robots.

Drew: Are there specific applications where it's currently being used that you could talk about?

Espen: We have lots of customers that are evaluating. As an example, FUJI Corporation in Japan is trying it out and using it for robots that will operate in a retail environment. Also there's a European manufacturer that I'm not allowed to mention specifically. They are putting our sensor inside a cleaning robot. We expect our sensor to be out in the wild in the not-too-distant future actually.

Drew: That's very cool. I feel like I'm getting to learn about Sonair right before its takeoff.

Espen: That's what we're hoping for.

Drew: You mentioned that the sensor could be used in cars. Would that be low-speed stuff?

Espen: Probably yes because of the speed of sound. This is not our focus right now because it's an extremely harsh environment to be outside of a car. We are researching this, but we don't have a solution right now to make it able to withstand the worst conditions. We currently have a rating of IP64, which is not sufficient for cars. The sensor itself is very interesting for that use. The question is just if we can get sufficient energy behind the shielding that's required.

Drew: My other question was about robots. Are there ways that the robot developer can use your sensor to get an understanding of the environment in terms of informing navigation, or is it more of a safety sensor primarily?

Espen: The focus is on the safety side, and we do get a pretty sparse point cloud, so the understanding part is hard. We have seen some experiments doing some kind of SLAM algorithms on top of it, but we're not sure if that's a perfect solution right now. Primarily, we're aiming for object detection.

Drew: I feel like a simple camera setup with a Sonair sensor could be a really compelling combination for a lot of projects.

Espen: Exactly. We also think that’s a very nice combo. You use our ADAR sensor for the safety, and then the camera for the navigation.

Drew: I noticed when I was researching that a lot of the founding team seemed to have this really specific experience in researching sound. Can you talk about the founding team and that background?

Espen: There's a lot of very, very competent people in the company. We started as a spin-off from SINTEF, which is a big Norwegian research institute that developed the core technology for sending out these sound waves. There's 20 years of research that went into how to efficiently generate the sound at these high volumes with little energy and in a very, very tiny package. That's one part of the company. We also recruited two people who have a long experience in medical ultrasound. In Norway, there are quite a lot of knowledgeable people in the medical ultrasound industry. So, we took their expertise and now we're applying that to ultrasound. Taking the technology from medical ultrasound and applying it in air has been one of the door-openers for making the progress that we have.

Drew: That’s what they call founder-market fit, right?

Espen: In Norway, we have GE Healthcare, Kongsberg, and we have this Center for Innovative Ultrasound Solutions that we're part of. Norway has these centers of excellence that are founded by the Norwegian Research Council. So, we're part of that whole thing which has been really good.

Drew: I mentioned earlier that Sonair seems to be growing really nicely. What are some of the big, recent milestones that you think are worth mentioning?

Espen: In May 2024, we came out of stealth. We spent a year and a half just developing to a point where we thought that this was worth showing. We had 20, now I think we have around 30, global robotics companies evaluating our sensor. In June this year, we launched the commercial product and we named it ADAR. It’s a product that you can buy. Two companies are designing it into their systems, and a lot of companies are evaluating it. We've also been able to get financing. So that's also a big milestone!

Drew: That's important in the early days.

Espen: It is. We are very happy with the investors that are backing us. They bring money obviously, but also competence and a strong network. We feel lucky especially in a period of time where getting backing has been pretty hard. We've heard of a lot of companies that have been really struggling. From a technical perspective, our product and technology are working. We've also managed to get it into a very small package. The sensors are not safety certified yet, but that is coming. And, of course we managed to release a functional product. That's a pretty big technical milestone.

Drew: Your specific role is as a Technology Manager and Founder. I saw that your background is in software. What pieces of the project do you personally spend most of your time on?

Espen: My role at Sonair is Head of Software. That’s my formal role. But, in addition to that, I also have experience from previous jobs on the safety side, so I'm the Safety Architect. I spend some time coding and a lot of time managing the software team. I also spend a lot of time planning, preparing, and doing the safety part and making sure that what we're building is certifiable. There’s also a lot of work that goes into generating all the formalities that are necessary for a safety product.

Drew: When you say you had previous experience with safety work, what do you mean?

Espen: I came from GasSecure, which was a Norwegian startup that made a gas safety sensor. It would sound an alarm if there's a gas leak in a factory or on an oil rig or something like that. That was also a very challenging project where we were the first wireless gas sensor to get safety-certification. I was Head of Software and also important in the safety part of the design.

Drew: Since we're already talking about this safety certification stuff, how does the safety certification process work?

Espen: There are a lot of different answers to that question depending on which industry you’re working in. For us, it's functional safety and industrial functional safety. That puts us into what's called the IEC 61508 world, which is a specific functional safety standard. For automotive, you have an ISO 26262 standard. Then, for rail, you have something, and for medical, you have something else, and so on. There are different standards for safety but the common denominator is that you need to follow some rules, and there's a lot of documentation that you need to produce.

Espen: You give this documentation over to an assessor, and the assessor does an audit and says yay or nay. For functional safety for industrial, it's actually a physical certificate that you get that you can hand over to your customers. For automotive, I believe it's more of an assessment report. There are slight variations there. But typically, it means that you have a lot of safety rules that guide the development process on the hardware side and on the software side. You need to follow processes, and you need to be able to document that you followed the processes. There are a lot of rules, especially in the standard we're following, on software quality. For example, you have to have 100% statement coverage of all your unit tests. You have to have fault insertion tests, you have to have hardware-in-the-loop, and software-hardware integration tests. There are a lot of things that are part of best practices, and I think most software developers agree that these things are good to have. But, in practice, depending on the company you're in or the business you're in, you do some or all or none of these things. In a safety-certified product, you don't have a choice. You have to follow these rules.

Drew: You mentioned earlier that there's not really a path to safety certification for AI-based systems. Is that because the safety certification requires some form of deterministic evaluation?

Espen: Yeah. Actually, one of many things that we need to do as part of our assessment is to prove the failure rate. In order to achieve Safety Integrity Level 2, we have to have a probability of failure below, I don't remember, four times something to the minus seven. As far as I know, there’s no pattern yet for making these statistical proofs for AI. There's a lot of work going into it, and a lot of people want to make it happen, but we’re not there yet.

Drew: Why is being safety certified an advantage to you? You talked about a lot of your customers; why is it a requirement for them?

Espen: It depends on which country you're operating in, but typically these are formal requirements from the government or the industry. In order to have a robot, it has to be safety certified. At least for the AMRs, my understanding is that if you're small and go slow, you don't need to have safety certification. If you're going faster than some limit or are heavier than some limit, then in a lot of countries including the U.S. and Europe, you're not allowed to operate without being safety certified. The typical solution for this is to buy the safety-certified LiDARs, and those are your safety mechanism.

Drew: Can you talk about how you ended up using Rust for the sensor and what role it plays in your stack?

Espen: Before Sonair, practically none of the people on my team had done anything serious in Rust. We had all heard about it and dabbled with it. We ended up thinking, "Okay, we know that this is going to be a new product. It's a chance to start fresh. Maybe this is the right choice." Rust was up-and-coming, and we were seeing people saying, "Stop using C and C++." Of course, we were most experienced with those languages. For the prototype, we thought, "Hey, it would be pretty cool to see if this can run in Rust. Rust is safer, and the product is important for safety." But, we didn’t actually start so much with safety in mind. Certainly when we started functional safety and safety certification were sort of on the negative side for us because Rust is not safety certified yet, and certainly was not at the time when we started Sonair.

Espen: Using Rust sort of came out of technological curiosity, but also experience with the pain points of C and C++. From a low-level embedded side, to get a compilation error if you try to use an input line as an output is pretty nice. You don't get that in C or C++. So, that's where it started. The more we worked with it, the happier we became. At some point, we realized that we have to have safety certification. Around that same time, Ferrous Systems in Berlin came out with Ferrocene, which was then in the process of being certified. We thought it looked promising and saw a path forward. There was a point in time where we were concerned that we would have to rewrite what we had worked on in Rust into C because of safety certification, but right now that's not what we're doing. Our sensor isn’t built 100% on Rust, but it’s pretty close. All the safety functions will be written 100% in Rust.

Drew: I have to imagine that Rust provides a lot of advantages when you need a very high level of predictability, right?

Espen: Yeah, and you sort of get the best of both worlds with Rust. You get the performance and low-level possibilities that you have in C, and you get the high-level abstractions that you can get in C++, but you don't get all the legacy issues. There are so many things that we all agree you shouldn't do in C or C++, but it's possible to do them, and sometimes you have to because there's no better way. My take is that Rust sort of took all the best ideas from many programming languages and put them together in a really nice package. Of course, when we started, the Cargo ecosystem was also a super big door-opener for us in terms of getting up and running fast as a startup. It just really gave us momentum and allowed us to focus on the stuff that is core to us and pull in third-party crates for the non-core side of things. The combination of the low-level ability, the performance, the high-level abstractions, and also getting all these third-party things is sort of what really made us love it.

Drew: Cargo is really excellent. Before it existed, especially for systems programming languages, there just wasn't tooling like that. What does it mean to actually safety certify a programming language itself?

Espen: That’s a very good question. In theory, the safety certification standards don't care about the language. They just require that you do this and that. They say stuff like you have to have strong typing and that you cannot do dynamic memory allocation. They don't really say that you can only use this or that specific language. That being said, you do have to do what they call a tools suitability analysis which is making sure you have a safe process for turning your natural language code into machine code.

Espen: Probably all safety-certified software is compiled with a safety-certified or at least safety-assessed compiler. When we started Sonair, that didn't exist. That exists now with Ferrocene. I know that there are other companies out there making certified compilers. So that sort of answers one part of it. That process is fairly well established now with Ferrocene being out. But for us, you also have libcore. You can't do a lot without integers, multiplication, subtraction, and arrays. At least at the time of this interview, that's still not certified. We are working together with Ferrous Systems on this as well. By the end of this year, there will be a subset of libcore that is certified. Hopefully that subset will be sufficient for us to use for certification. Then, we have to prove that the code that we write is according to the rules and regulations for the safety standard that we're following. That more or less prevents us from using third-party crates. All this nice cargo add stuff can’t be used. That is going to be a big effort for us. We either have to reinvent what we're depending on, or we have to lift the third-party things that we depend on to a level as if it was written by us. Every single line of code that executes in our system needs to be according to these functional safety requirements.

Drew: That sounds hard.

Espen: It’s a lot, but it depends a bit. If what you're doing is well-documented, well-designed, and there are tests already, then you're halfway there.

Drew: From my vantage point running a Rust hiring platform, the thing I'm most excited about right now by far is robotics. I think Rust is going to explode in robotics, and I think robotics itself is going to explode in the next few years. A lot of the pieces that we need are finally coming together to make robotics really work. How do you think all this work that you, your team, and the people at Ferrous Systems are doing on safety certifying Rust will play into the future of the robotics ecosystem?

Espen: We're lowering the barrier for the next company to use Rust. We're pushing Ferrous, they're pushing us, and hopefully we upstream some of the things we do. We're sort of establishing methodologies and ways to get safety-certified Rust. I think it's a pretty general consensus that Rust by design is a safer language. But, right now the norm in the safety certification process is to use C and C++. It’s counterintuitive but that’s the way it is. Robotics is a lot of high performance, but it’s also typically distributed systems. It’s pretty hard, non-trivial software. I think Rust is a really good fit there. As robots become more present, more and more robots will interact with humans, and I think this will also increase the need for safety in robots. I think it fits quite well, and my expectation would be that we'll see more safety-certified Rust moving forward.

Drew: Is Sonair hiring Rust engineers at the moment?

Espen: Right now, our technical team is more or less the right size. We have more recruiting on the sales and the commercial side of the organization. We're pretty tech-heavy right now, being a startup. But we're always looking for talent. We're definitely interested in talking with people who are interested, but we're not actively hiring right now.

Drew: When you do bring in new employees, what are the traits you’re looking for?

Espen: In general, I would say, "hire for attitude, train for skill." We are a low-level, bare-metal company, so obviously embedded experience is important to us. We also have high-level algorithms. We have some people with a lot of embedded experience and some people with more algorithms and mathematical experience. Both are valuable, and we meet in the middle. It’s a very fruitful collaboration. I would say that no one on the team had a lot of Rust experience before joining, and the rest of the team didn’t have any Rust experience. However, everyone has lots of experience with software development in general. Even without experience though, the journey to adapt to Rust has been super smooth. We've all felt very much at home. Making the decision to use Rust at Sonair worried me at first. I wondered if it would impede recruitment? What we've seen is the opposite. I have a feeling that we're attracting better talent through Rust because the people who like Rust tend to be forward-leaning, so we are very happy.

Drew: That's an important point. I don't know if anyone's ever said that in one of these interviews before, but I absolutely agree. From everything I've seen, using Rust, and especially using it a lot, is a recruiting advantage. Is there anything you would mention about the culture of Sonair?

Espen: Well, what I'm most happy about is that we are all very skilled in our individual specialties, but we're also quite cross-discipline. In Norway, the typical organization is pretty flat. There's not a lot of hierarchy, which I guess is pretty normal in a startup generally. But we're also taking that to mean there's a lot of collaboration between the different specialties: electronics, ultrasound, firmware. We are organized in teams, but we certainly help each other out a lot. So I think that cross-discipline communication is unique, and I think it plays an important role in our success so far.

Drew: Okay, amazing. Thanks so much for your time Espen!

Espen: Thank you!