 And we're live. Hi. Hi, my name is Iwas. I'm Product Manager for FItec. And I'll be showing to you today our FIline BS piece, what it's all about. And so this is specific Linux support that FItec is providing directly onto every board or how many boards are supported? Well, we're starting off with a few boards currently we're focusing on I don't know makes six UL based Psalms and SBCs that we support with this FIline BSP mechanisms. But we are continuously adding new boards like, for example, the I make six is the next one to come. And then we're moving on to the new I mix eight derivatives as soon as they are available mainline. So for our system that we are using, we need mainline support for the for this board in order for it to work. So we have to wait till mainline is available. Nice. If you don't mind maybe just pushing your mic just a little bit further away from your mouth just so we get like that. So so FItec is famous for providing a lots of boards, right? You do all kinds of boards for the embedded market for very, very professional things to also coffee machines, like all kinds of stuff, right? Yeah, that's right. So we provide the core product for any embedded designs. So if you are requiring an embedded design with a typical Cortex-A processor, for example, from TI or NXP or whatever, you can take one of our Psalms and you can design it onto your own carrier board. And your carrier board is then, yeah, adapted to whatever application you have with all the interfaces and the Psalm as a core design, core embedded design will then bring you all the functionality. We also have single board computers that are sort of like a reference design for these kind of designs or they can actually be used in a series product and if it's applicable to the requirements of the application. So BSP means a board support package, right? Yeah, that's right. And what do you mean by a new approach to working with Linux? So what's new about the way you're doing it? Well, in general, you have the possibility to use chip vendor BSPs. The chip vendor, for example, NXP or TI or whoever RockTrip, they will provide an applicable board support package to go with their chip. And then we as a Psalm vendor, we typically create variations of these BSPs, adapt them to whatever we have changed around the processor, like the memory that we added on our Psalm files, Ethernet files, things like that. And also all the active components on the carrier board that might have been different from what the chip vendor has foreseen. And we make all these changes and then we provide the BSP, the vendor BSP change to the functionality of our boards and customer can then use that BSP as a basis for their development, make additional changes if they need to, and yeah, and then go on from there. And typically we provide everything up to the application layer within the BSP. So we do all the driver support for the components, the active components. And we make sure that middleware components that are typical in when it comes to embedded designs are also functional. And those are the basic offerings when it comes to a BSP. But Phyline BSP is a little bit more than that. It's actually a CI based distribution. So what we do is we look as soon as the critical mass of features are supported for a certain processor within mainline, we switch supporting from vendor BSP to mainline BSPs. So we take the latest kernel, latest Yocto versions and from mainline and then we adapt these to our board so that these new versions or these mainline versions of Linux will be running on our hardware. And that's the basic task that you have to do. And then from there on we have a CI system that continuously grabs the newest state of the mainline kernel and Yocto version and it compiles it and tests it with test cases that we've created and it makes sure that everything is running. And as soon as something is not running due to changes that happen in mainline, we fix these changes and we commit those changes back into or those fixes back into mainline so that we ensure that all of our hardware is always running with standard mainline kernel. You can just download the mainline kernel, configure it to the Phytec hardware by just selecting the hardware it's supposed to run on and then it'll run automatically on our hardware. So that's the basic idea, we bring our hardware mainline and we have a continuous integration system that continuously tests the state of our boards within mainline. So for example in this slide that you're showing right now, you can see at the beginning when a board or processor is coming out from the chip vendor you see that only the vendor BSP is the best thing to go with because that's a full feature set. And after a while mainline takes up on these processors and they start supporting the features of this processor and at some point the feature set of the vendor BSP is the same as the mainline BSP feature set and that's where we say okay now it makes sense to switch to a mainline BSP and then start integrating it into our CI system and then do all these continuous tests and make sure that our board is also our board specific adaptations are also integrated into mainline. So that's the basic idea. So when a customer comes and buys a board, what can they expect from Phytec or the support is going to be there in terms of they get the latest kind of like security patches and everything that's from the latest that can be possible for that board? Yeah, so that's the next step. So we've integrated our board into Linux mainline and typically the customers don't want to use the latest master of mainline because it might become instable or something like that even though we've tested it. It's a good idea to go with LTS releases. LTS releases are releases that are announced by mainline during the work since the master is continuously growing and growing with new features and new code committed by the community. There will be at some point the announcement of an LTS release, which is LTS stands for long term stable, which is then frozen in a feature set and the feature set is then frozen, as I said. And oh yeah, you can see it right here. So for example, if you look at the green spiral, that represents the continuous involvement of the Linux master, right? And during that time, there's announcements like on the bottom, you can see 4.19 thud, this little green box and the one above, so it's three green boxes there. And within these releases, these frozen feature releases, there's only going to be maintenance for bug fixing and for security fixes. And the community does not add any more features to these releases. They are actually branched out and they run parallel to the mainline master. Yeah, you can see it right there. That white spiral is then the branch of the LTS. And as I said, there's no new features added, but there's continuously fixes added to this branch. And so if we create a release out of these LTSs, our customers can then use this LTS for a long time and they can base their application on that. It's been tested and everything and yeah, they can add tests if they like to whatever they have added and then they can deploy it to the board. And then we have this CI system in the background that always takes the newest patches from the LTS maintenance path and takes this from the mainline and then adds these LTS patches to our releases on top of them. And then customers have the possibility to update their system continuously. Yeah, it shows right here. So in between, we might make some more releases, but in general, we continuously take the newest LTS patches every night on a nightly basis and we build these releases with all the new patches. We test them again to ensure that none of the features that were supported in former releases are then lost. And yeah, we do that for every LTS. So if there's a new LTS release announced by the community, then we take that. And because we have continuously maintained our boards in the mainline master branch, it's easy for us to create a new LTS once it's announced. So there's no big gap between the LTSs and we have to do a lot of adaptation to our code again in order to make our boards work because they're already supported in the mainline. So when people become customer at Fitech, they can expect kind of something like 10-year support or this is when you put the board into a coffee machine and the coffee machine goes into a company, it's going to stay there for 10 years maybe, or for example, right? Is that like a why you have to have a whole update system that's secure, safe and easy and automatic and everything? Well, the thing is, of course, in general, when it comes to hardware, our minimum lifetime that we guarantee is 15 years of our products. This is based on the guarantees you get from the industrial-based processor vendors, which also guarantee 15 years. We actually have products that's been on the market for 30 years. We don't discontinue any hardware. And typically the chip vendors provide their chips much longer than 15 years. Those are only the guaranteed run times. So let's say 15 years is a minimum, but typically up to 30 years, you will have a product supported by us in terms of hardware. When it comes to software, vendor BSP is not supported for, I don't know, 30 years. So at some point, the maintenance might stop. But since our boards are integrated into Mainline, the Mainline will continuously maintain this board and consider any changes that might have to be taken to support, continuously support our board. And we also make sure that our boards are continuously supported within Mainline for at least the runtime that we also provide the hardware. And that's why we go Mainline, because then we are independent and we can make sure that you will always have an up-to-date BSP with latest security fixes and so on. Is it possible that some customers don't want to update too much to be disabled some of these updates because it might introduce some kind of instability or something like that for them or most of them will just say, hey, I want to update automatically with your system? No, I mean, in the beginning when you're designing your board and you're bringing it out to the market and you want to bring in new features to your product when it's already in the field in order to keep your customers happy and loyal to you, you bring in new features just like iPhone where you get the new OS version and you get all these cool new features. Same thing you can do with your product when you're using our Fireline BSPs because you will always get the newest LTS versions of kernels. You will actually be able to also have the Mainline kernel to take new features from there. And this is kind of like the growth phase of a product where you want to do things like that. But at some point the product goes into a maturity or even decline phase and then you're not so much concentrated on adding new features and so on. So then you will just want to make sure that since your system might be connected to the World Wide Web, you want to make sure that you continuously maintain it for it to be secure. And so then you don't need these continuous releases all the time all the newest features, then you're more concentrated on maintaining security patches. And that's where the LTS kernel comes in into play because then you typically have a long-term support of security patches that you can always apply to your board without having to do major changes to your operating system. And so we try to foresee both phases. At the beginning, we want to be up to date as much as possible, bringing always newest kernel and Yocto versions as fast as possible in order for customers to be able to take care of all the innovative features and use them from Linux. And then when the customers are not so keen on new features anymore for a certain product, that's when we also switch to a release cycle that's a little bit longer from one year to two years. Every two years we release a new release then. And so customers don't have to do these major updates all the time. They can at least run for two years and have security patches for this timeframe. So is this showing what you've been doing over the past year or? Yeah, that's kind of the example of our release strategy right here. So on the bottom in the purple, you can see our releases and in this example, it's a product that is still in the growth phase. So therefore we have over two years, we have two releases. One is a LTS Yocto release. It's Dunfell based, for example. And this Dunfell is supported for two years by the community. And so therefore as soon as it comes out, we try to support it and using the newest kernel, Linux kernel as well on top of that. And then we've maintained that with our continuous LTS patches, security patches over the full two years. But since this product is still in the growth phase, we also do after a year another release taking the hard knock Yocto release and making another release, which is also continuously maintained with security patches and so on. So for a customer that doesn't want all the innovation and change to a big kernel, he can use the long term two year release and just maintain that all the time. And if the customer needs a very innovative features from the newest Yocto version, he can take that second release and use that and make the change to that. And after those four or two years, the whole cycle begins again. And so at Phytec, you're working a lot with NXP, many other chipsets. TI, ST, Rockchip. All these, how would you, I guess maybe some Linux developers have some favorites over the others in terms of what they've been doing the last five, ten years and what maybe one can expect will be done in the next five, ten years. Because it's also important for the chipset provider to provide also extra support in the whole Linux ecosystem, right? I don't understand the question. Yeah, so what I'm trying to say is do you have any favorites or can you tell some stories in terms of how good the support is coming out of NXP, TI or... Well, in general, the support is very good. NXP, for example, they have evolved a lot into also supporting their boards into Mainline. They're still focusing on doing their own BSP releases and sometimes they break with Mainline compatibility and so on. And so some features might not work. But in general, they are more and more working into Mainline and that helps supporting their chips over long term. And so in addition to that, also NXP, TI, for example, they also have a good Mainline strategy and their boards are then long term available in Mainline. And we take up this strategy and then we support it for our hardware and using our CI system. We do these continuous tests to make sure that there's no breakage within compatibility. And here I'm adding in full screen the update and device management slide that you have. It's a big part of your value proposition is how this functions. Yeah, I mean, if you have created your newest images for your BSP taken from our Phyline BSP offerings and you have a new image that you want to update your device with, which is in the field, you might think, how do I get it up there? How do I upload my new image? And that's where we also have a solution together with our partner OSB. It's a full on update and device management platform. So it actually helps manage all your devices when they're out in the field and they're connected through the internet. It's a hosted system on a server and all the devices, all your devices in the field automatically connect to this platform. If you wish so, we can even pre install all the required keys and certificates when we deliver hardware to our customers in order for our hardware to then connect automatically to the system and is then viewable in the customer's user account within this system. And the customers can actually, of course, do all the updates. These are all secure updates using AB partitions. So if your update fails for any reason, your system will still be reachable because there's a backup partition that will hold the old system used before the update. And so that's a secure mechanism. In addition to that, the whole system is also secure in terms of authentication through keys that are on the board that we can pre install before delivery. The whole communication between the system is also secure by encrypting the communication channel. There's also always measurements taken care of so that no image can be installed to the hardware that is not supposed to be installed on there. So all images are being signed by the platform. And so only the user that can access the platform can make updates using the images that he wants to be on the board. All these kind of security mechanisms are supported. And also there's a device management part in there within the system. So you can see the status and the health of your system, of your boards. You can have statistics of your boards, how they behave. What is also included is a SIM card management. So if your devices have SIM cards, there's actually wherever SIM as a provider for SIM cards, for roaming SIM cards included into the system. So you can manage all your whole fleet and manage the SIM cards that are in your devices. So that's really a full on solution. And instead of needing to design your own device management and update using all kinds of components that you might find in the internet, you can use this system and you won't have any investment from your side in creating the system. You can concentrate on your core business and just use this system and you don't have any design risks when needing to create this. And on your slide it says up to 100,000 devices could be managed this way by one click. The administrator just clicks and then 100,000 devices could be updated. But how about is there like a strategy in terms of when is a good time to update? People do that at four o'clock in the morning or something. Does it take five minutes for each board to update or how does it work? Well, you can manage all of that. I mean, it depends on your servers and the connections of the devices, how you want to do it. Typically, you wouldn't update 500,000 devices at the same time because your server would probably be the threshold on this. In general, I mean, this system is running on AWS and it's hosted by OSB and so there's a lot of server infrastructure behind it and you don't have to really worry about that. But still, you don't want to have all your devices updated at the same time. For one reason, you want to make sure that the update really works. So you will probably start off with a couple of devices and see if everything goes well. And so you can do that by creating batched update mechanisms within the system. So you can actually say you can group your devices, say, OK, this is a group of devices that should be updated now and the other group should be updated afterwards. If the first group was successful, for example, and then you can just start this batch and then the system will automatically start updating the devices then see if it was successful and then continue on from there and start updating more devices as it goes. It can also, since you can group the devices, you can also differentiate the images that will be updated to the devices. So for example, if you have devices in the US, you might want to have a different image on those in comparison to devices in Germany or in France or whatever. And so you can actually group these devices saying this device is in the US and then it gets this image. And then on the other hand, if you have a device in Germany, this one gets another image and the look and feel will be different or the language would be different, things like that. So you can manage all of that with this update and device management platform. So it's really usable for a large fleet but also only for a small amount of devices. It's also suitable. So for example, if you want to do debugging of a single device, it's possible. You can connect yourself using SSH or other kind of secure tunnels and actually get direct access to the device as if it was on your table. And then you can do analysis or make changes, upload files and things like that. What is on this slide right here, SLCM? Yeah, well, that's actually Fireline BSPs for customer hardware. So as I explained, we take our hardware, our Psalms and our carrier boards. We put them into our continuous integration system. We run these continuous tests and the customers can take that as a basis to adapt our BSP, which is then maintained with the LTS releases. He can take that adapted to his carrier board and the changes he might have made for his application and then make some more tests and then deploy it to his device, the software. But if he doesn't want to do that and he doesn't want to maintain his own hardware on top of what we've already done, he can also give his hardware to us and we can integrate it into our CI test system and we can test it just as well as it would have been our board. And we actually also integrate specialties of his board into mainline and commit changes that might be required for the Linux to run on his board. And so we maintain his whole board within our CI test form and he can take any release that we create on the nightly builds and use it for his productive system. So he will get the same offerings as the Fireline offerings with the mainline kernel supported for his hardware with the LTS releases supplied and also the security patches on top of the LTS releases that continuously come. He can take that and run it directly on his carrier board and he can also get customer specific tests. So if he says Phytag has a nice test infrastructure and I like the tests that Phytag is doing but I need some more on top of that because I have a special feature that I need within my application and it needs to be tested every time. We can implement that test for the customer and then do the tests all the time shortly before we do a release for this customer hardware. So that's the basic offering. If I go right here on your website, there's a lot of boards, system on modules. There's a lot of choice for your customers. But I guess what you were saying also is that there's different levels of customization that they might want to do. And if they do a very custom board, the support for the Linux is different than if they take something more generic of what you or is it something to do with that? Well, I would say from an embedded design, a certain percentage is always the same since our Psalms will always stay the same. They will be within the customer application and the memory interfaces and everything will be the same. So a certain percentage can just be taken as is also in the software. But then on the carrier board, there might be active components that need to be considered within the Linux. That's where we offer the reference design, the single board computers that can be used in serious product. But they can also be just used as a reference design if a customer wants to do his own design. Or we can design his carrier board for him as a service. This is also he can specify it to us and then we design it out. So for example, here what you're showing right now, that's a design service where we actually reuse functional blocks and we have the capability to design a carrier board within very short time and at a very low cost by just reusing circuits that always pop up when customers have some certain requirements. Can you say something about how many of your customers go full custom and how many just go here and just buy one that's already kind of like no need to customize? Well, the single board computers are a small percentage, maybe 20% or so can really work with the single board computer as is. That's why we've created this adaptation service where we take a single board computer an existing single board computer and just make some small changes to it in order for the customer to then have his requirements, have his own single board computer, which is based on the basic design that we've made once. So that's a bigger percentage. In general, you can say, I would say maybe 50% of the customers do their own carrier board design and 20% take a single board computer that's maybe adapted to their requirements and 30% of our customers get their own design made by us. That's typically, I would say, typically the percentage. And so you have a whole team of Linux, what's it called, experts working at Fitech doing all these Linux support. Yeah, so we have a large team of, I don't know, it's more than 10, maybe 14, 15 software developers that are just continuously working on maintaining Linux and doing customer-specific adaptations. So upstream? Also upstream, that's work in parallel. So we maintain our BSPs and in parallel we monitor what the test system is giving us, saying, okay, there's a problem here, you have to fix it. And then, yeah, he puts aside his work and then he continues, he concentrates on fixing things within Mainline and then he goes back to working on the next release for Fitech. I've been doing videos with Linaro nearly for 10 years and the support that the ecosystem is doing for Linux on ARM has been accelerating. Like maybe in the last two, three years, things are getting even more and more smooth and better and Linus Torvalds is happy. Yeah, so yeah, I mean, Linux is picking up on new processes very quickly and the features are continuously being added. So it's for industrial use, it's a very interesting operating system and we see 90% of our customers using Linux. So yeah, it's a very good interesting operating system and I mean, if you look at the future that you can foresee with devices going to the field and being maintained remotely and features being added, companies adding new features continuously, having the possibility to get new ways to make money by adding new features that cost micropayments that you add during the lifetime of your product. All these kind of things, that's completely a good fit when having a Linux that you can maintain and you can keep secure, right? So I think yeah, it's going to continuously grow the usage of Linux within IoT devices and connected devices around the world. And there's more and more security hardware based security on these newer SOCs that support extra layers maybe of security that just get supported and maybe opti or something with the Linux and security systems in there. Yeah, so we have a special team concentrating on adding all the features, the basic security features that you typically require when you make your system secure. For example, secure boot, key handling, encryption of data encryption of the file system, all these kind of features we prepare within our BSPs, make sure that they work as well as the update client that needs to run on the hardware for the update and device management, which is also always integrated. So on top of maintaining the Linux BSP, you need to take care of all these other Tempor Protection, for example, is another feature that you should take care of if it's required for your application. All these measurements are prepared and we also consult the customers in creating a security concept for their product applicable for what is required in their application. So right here when I check on your website, it says the IMAX 8 family starts at 44 euros. When people buy one, let's say, I guess for one, it's maybe not the same price as bang many, but is the support included or does support is paid on top or there's different options, right? It depends how custom the support is. Well, in general, the support is if you buy an evaluation kit to try out our hardware and get familiar with the system and the Linux, we support that fully for free. So we want to make sure that you can evaluate our hardware and you get everything running. So that's a free support. And then, of course, it depends on what you're doing. I mean, if you want to do your own carrier board design, we support you with that. We have an FAE team consisting of four people making sure that you are successful with your design. And because our interest is that at the end you are successful with your design and you sell a lot of products in order to buy our carrier boards and system on modules, right? So we support you continuously up to the point where you finished your product. I mean, of course it depends. If you need, for example, special driver implementation for something that's very special, then that would not be covered by the free support. Then we'd have to create some support contract together. But in general, we support you as far as we can in order to bring you into series. All right. So thanks a lot. So this is what you were talking about at the Embedded World. You did a presentation about this. Yeah. I did a webinar where I explained the Fireline BSP mechanisms in detail. So, yeah, if you're interested in that, go to Embedded World. But you will also find the video on our web page. We also have a Fireline page on our web page, which will be launched soon. And there you can see all the test results. You can download the images that are being nightly on a nightly basis created. And so there's really where everything is happening. And here, I'm just going around in terms of on your support pages. But you say that you're adding some stuff around there. Now, it will be in the services area. That's where you will find in the software services area where you have your mouse pointer right now. There will be a new topic, Fireline BSPs. All right. So that's the basic offerings of the standard BSPs and Fireline will be added to Fireline BSPs. What's the response from your customers? Are you measuring some enthusiasm in terms of this is what they've been asking for and you're delivering? Well, it's pretty new. So I will see how much the customers will take on on this. But I've actually done interviews before I started this project. And therefore I could identify that customers have exactly that need. And that's the basic idea. We focused on creating a solution for exactly what the customer needs when it comes to maintaining a Linux BSP. And on addition, the webinars are very well met by customers. So there's a lot of customers looking at the webinars, which is nice. So it shows that this is a topic of interest. And in addition to that, we already have, as I shown you the SSEM offerings, we already have customers that have come to us with these certain requirements, asking for us to deliver continuously updated versions of LTS and also mainline Linux. And so over the past year, since we did video physically at Embedded World 2020, has the market grown? And like, even though everybody's working from home, all the different companies are at home and everything, but the embedded market has been growing. It keeps growing. Yeah, it's amazing. I mean, there's new projects coming in continuously now. So when the first pandemic wave came at us, we had like two months with a little dip where there was not much activity and we were like, oh my God, what's going on here? But after these two months or three months, I think everything has settled and people got used to working differently. And yeah, things went back to the new normal. And then all of a sudden new projects came coming in and people became active again. Yeah, everybody learned how to work together with remotely. And so, yeah, so things are going back to being great and the market is really working. And some things have changed. Some requirements have changed. For example, voice recognition is a big topic that we also have solutions for where you don't want to touch things because of any danger of getting infected. So voice recognition solutions are now a big hype and things like that. Hopefully we can do a video about that. Hopefully we can do a second video about the voice systems, right? And maybe I wonder, are you hiring people or do you have people only in Germany or around the world working on this stuff? Well, Germany is the headquarter and our production is also in Germany and the development team is here in Germany. But we also have a development team in the US and also a subsidiary with sales and everything. And on top of that, we have a subsidiary in France, in China, in India. So we're actually globally spread around and we can provide services to any continent around the world. All right. So did you think we forgot to talk about something in this presentation or we covered the whole everything? I think basically we covered everything, yeah. Cool. So thanks a lot for talking about your latest Linux support innovations happening in the special way you're doing that. Yeah. All right. So thanks a lot. Thanks everybody for watching and hopefully we can do more video about the voice and some other topics later. Okay. Yeah. All right. Thank you and thanks for listening. Bye-bye.