 Yeah, welcome to my talk on the great topic concerning distributions and a question actually to you as the audience. So we are preparing an open source project for embedded devices, which supports Linux-based embedded devices more with the needs of such devices. Open distributions typically support desktop or server use cases and we want to specialize on that. And I'm basically asking the question, do we need something like that and I will go into detail what we plan and hopefully we can, yeah, I can get some feedback whether you think this is a good idea or not. My name is Lars Geier-Blaumeiser, I'm from Bosch.io, which is a subsidiary of the Bosch Group and basically, yeah, this is an initiative of the whole of the Bosch Group. I'm only representing Bosch here for today. So that's what we plan to have an holistic approach for product diversity based on Linux. So it's more than just a distribution, it's also an infrastructure and all the stuff needed to easily build products based on Linux, especially as I said, embedded or IoT devices built on Linux. And there is already a blueprint for what we plan because there is already a project where Bosch also participates and invests a lot. It's called Apertis and here's the mission statement for Apertis, a versatile open source infrastructure originally tailored to the automotive connectivity needs. So it was built by a Bosch business unit around calm multimedia. So it's more about, yeah, multimedia devices for vehicles, but we saw that it's also fit for a wide variety of electronic devices. So we use this also in other business units nowadays and that's the potential we saw. And before we solve this internally, we thought perhaps it's a good idea to share this with the community and get other companies also into this initiative. What Apertis is all about, big important parts of Apertis are of course security because it's connected devices, they have to be secure and modularity. And I will give you a glimpse in the talk about what we mean with modularity. It provides a feature rich framework supporting add-on software and resilient upgrade capabilities. So, of course, updating is this topic. Beyond an operating system, it offers new APIs, tools and cloud services. So it's also the infrastructure and the services around the core distribution. Coming to Bosch, so I'm from Bosch and why are we interested? Basically because we connect everything. So there are so many different business units at Bosch who provide IoT devices. And here you see in the first column you see more tracking, management, device management, use cases. So, for example, we have all these here are products or projects we had so far. There is a project to manage connected filters which are placed somewhere on the lower left side. You see track my tools, it's for workshops who use a lot of power tools, drill engines and stuff like that. And they want to manage where are they on which place where they build something do we use certain tools? Eating systems are nowadays typically intelligent so you can also control them in your smart home environment connecting them with your house. We have lawnmowers or gardening stuff, household appliances which are connected nowadays. The third column is more on the industrial side. So industry for zero is of course a big topic for Bosch but also tools and systems in the logistics area. And finally on the right hand side also some nice topics in the agriculture or more agriculture areas, internet of oysters, monitor how your oyster farm is running. And finally of course the topic of software updates over the air is a big topic at Bosch. So you see a wide variety of things and this is really an amazing number. So Bosch produces one million things a day. So it's really a large number of devices which are connectable. Not all of them are then connected of course but which can be connected in principle. And that's why our chairman Mr. Denner said three or four years ago that he expects every electronic product to be internet capable to be connectable and for him the question is not whether this will be the case but only when this will be the case and that's when Bosch changed the strategy towards yeah being able to connect everything they produce and this is the way we are still going. We have lots of connected devices but still there are some to remain and of course new developments need efficient development methods. So if you look at typical demands of today's industrial devices we see that there is quite some change when we compare with Bosch products for a few years ago. Today's system evolve so if you have a not connected device development typically more or less ends when the product is raised to the market in the car area for example there will be perhaps some updates bugs that are detected in the field or for example changes to the legislation exhaust gas legislation for example requires changes in a project but typically it ends at the start of the product. Nowadays with a connected device development lasts until the end of the product usage so you always have security issues you have connectivity issues and you have to be able to maintain and develop the software over the whole lifetime of the product. Also products are integrated so we have a thing in the internet of thing is not a valuable thing except that it provides data which is then integrated into an IoT service and the value comes then with the IoT service so we have the things integrated and yeah they have to talk to each other and exchange data. We have topics like time to market which is rather short these days so products come into the market really fast with this means efficiency of development and of course that's also something Bosch observes that the highly inventive areas are typically nowadays open source ecosystems where collaboration in those ecosystems enables new trends to appear magically more or less so it's not one company that is providing the innovation but a set of companies pushing the innovation forward and finally what we see is that there are blurring boundaries for products so what you on the one hand see for example in the in the production area is the batch size reduction and the same applies for products so you have more and more specialized products which are related to other products but still they are specialized and fulfill very specific use cases on the other hand side you also see that by using existing products you can or by having existing products and the hardware of those existing products you can easily add new services a good example for is here cars where you can add new comfort functionality or or active or passive safety functionality on top of the existing sensors so the customer can buy additional services and they are installed only as a software product on his car so these are the trends we see and when you look then at the software what are the typical demands for the software one is of course that you have optimization for a specific hardware so there are of course standard hardware architectures standard reference boards that are available but typically the product then has a very specific board design with potentially hardware devices which are unique for this device and the specific optimizations for that are needed also size of course because you want to not over size your products optimized for the specific functionality this could also be for example environmental influence like the place where the device has to work for example in a car in a dirty area or somewhere where you have a lot of sunshine and it's very hot and stuff like that are very cold so also an optimization for the functionality of course the systems have to be secure so we don't want to risk security issues they have to be reliable they have to work without maintenance direct maintenance for a long time they might have a user interface but that's typically as you know from embedded devices simplified it's not a feature rich user interface it has to integrate into the relevant environment be it the connectivity be it the sensors and the actuators but also for example if you want to place it in a car it has to match the space in the car where the device has to be installed and of course you want to easily plug and play connectivity so whoever has built up a smart home knows what a pain easy or not so easy plug and play connectivity can bring and I mean many of those systems are not really maintained in the sense that there's always someone around to check what's what's going on so they have to be easily connectable and stay connected over the time. Security I already mentioned hardening against any kind of attack you don't want to get the data corrupted or listen to from from people that don't have the the right the right to to read the data but you also don't want to have your devices be the source of a denial of service attack for example so by having those millions and billions of devices in the world they're of course attractive to start such kind of attacks so they have to be hardened and secure to not allow such things. When you talk about embedded devices you also talk about commercial products components and proprietary components so you want to a mix of open source of course but also add some proprietary stuff that might be bought or developed in-house and for all those components be it open source or proprietary you need a life cycle management of the used components so you need to know which components are in so that for example you learn about a vulnerability that you can react and know where this vulnerability might affect products and can also analyze whether the vulnerability may have an impact on your product and if this is the case and you have to update of course you need a reliable update system so you don't want to have sorry you don't want to have updates breaking and and making the device to a prick that is not running anymore so you need a mechanism that doesn't atomize update but of course you also want to ensure that only those updates get to the device that are really really needed that are coming from you and not from anyone else and are not corrupted on the way and yeah we talked about efficiency so it's of course about the use of infrastructure and of general components things that are not non-competitive of course those you want to easily use and and don't want to invent more than once in your organization and finally one typical demand we see today is also that you have this two level of trust so you have a trusted base system which you control completely but you also want to enable the customer to add services applications on top which are not in the same trust zone as the base system but which are able to run reliably on your device and yeah the customer is able to to select which of those he wants on his device okay so that was basically what we what what the requirements are we see in in in the field and now there I want to talk about what we think is or is part of the answer at least a new open-source project basically founded on on top of of a practice we call it as a working title industrial great linux and I will come to you to what what this really means so the core idea is of course there is this multitude of open-source projects and all of them do something special and and and are making sense but in the end to use them in an industrial setting there is simply more than that and and the first step is to package them so that they that they fulfill a yeah a unique they have unique properties in how they can be used and that's for example something the debian universe has solved very well with the depth packages and and all the the infrastructure and and processes around that to select the appropriate open-source projects to pre-qualify at security policy management and and compose make compositions of them and basically we want to instantiate the debian process to even more narrow this down for the purpose of embedded devices IoT devices um so we would select the parts from debian that are relevant for that we would add stuff that's relevant for embedded also improving or increasing the enhancing the the infrastructure so that it supports also the embedded use cases to build the industrial great linux and that's then the thing that can be used by companies like Bosch and I'm showing the Bosch use case then on the right side can be used to build IoT devices so it's then again to enhance and reach the the open stuff with these special things that are needed for the different areas for example mobility or industry or residential areas so that we can build a multitude of IoT devices out of this core set of basic functionality and create products out of that so we widen up again and provide the necessary infrastructure and and a base system so that we can easily build those IoT devices so the idea is from a variety of open source coming to a very tailored distribution specialized on the embedded IoT use case which is then enlarged to be used in many many IoT devices and I talked about industrial strength so what do we expect from this interface here where we have this open components so to be able to use such components there are a set of constraints or properties that are needed to make them easy to use one thing is we want to have them as source or binary so there might be build systems like for example yokto which would rely on the sources but the standard build system provided in a purchase for example is based on on build packages optimizing them then during the image build we want to have them tested in reference systems so one idea is to provide a set of reference boards which are used or which are used to test certain compositions of the distribution and show that the software in principle runs on this reference systems and it's then part of the open source system to define which reference systems are relevant and should be part of this validation step. As BOM enables software bill of material enabled means that we want to have identifiable objects so even in the case that a project says I use a certain open source project but not as is I want to do some modifications the idea is to have the right working model the right process in place so that they can still fix this changed piece of software make it identifiable by having for example an a versioning scheme that allows them to state which component they're using which is the base component and adding that they have modified this component so that it's still manageable that we use this exact piece of software. Why do we need this basically for two reasons or there are multi more than two reasons but the two more most prominent are of course open source compliance so we need to identify which components are in a system and then which licenses applies to each and every component in this in this bill of material so that we can fulfill the license obligations of the of the whole system so but here we really need the reliable information so it's not only a declaration but it could also include the analysis of the sources so that we also find hidden licenses of files which have been copied into the project stuff like that and of course this the second reason for second important reason for the bill of material management is of course vulnerability management and this yeah is then relevant over the whole life cycle especially because vulnerabilities come in every time so anytime so you you don't know when and you also have to monitor your products in the field to be able to react on detected vulnerabilities and for that you have to know which product contains which component and all this this informations and additional stuff add to the quality of the components to the meta quality of the components let's say and make them ready to use so lots of of effort is spent in companies like Bosch to provide for example the open source compliance stuff and a lot of energy is burned doing that so having here efficiency really would improve the quality or the the speed of the process also the quality assurance the validation in reference systems that allows to get started fast and finally of course by having this this bill of material we are prepared for long-term support so if there are requests that come in later we know which components are in we can do any kind of update strategy be it a general update or be it for example only a small update in a certain component to make only minimal updates so everything is possible is transparent and can be used over the lifetime of the product the other thing what we expect at at this borderline is an infrastructure extension so there will be an infrastructure or there is an infrastructure in the open that does all this testing and all this this information retrieval and the infrastructure that is then used within the company to build the product should basically be an instance of this open infrastructure and it should seamlessly integrate into the open infrastructure so that there is no friction on on this move from the external to the internal usage of the component here again another picture on on the aspects of the project so in green you see really the software that is part of the distribution in blue you see the tooling around it and in gray you see the soft parts of the open source project the soft skills let's say of the open source project so in green we address basically four different pieces or types of components on the lowest end you have the hardware pack so that's really the software which is hardware dependent which supports a certain hardware to be executed with with this stack the next level the os pack is basically the the core of the distribution so the operating system but also all the packages that are for example the building the middleware and and supporting certain use cases libraries stuff like that and that can be chosen to be part of a product the third level then is um add on software in deployment so here we talk about applications that can be installed on on the device also after the product release for example we think about technologies like flat pack or snap or also even docker to allow to add software while the product is in in the field and yeah provide the services so that this can be integrated into a product that this is possible to to add software and finally on top cloud stack integration we also want to provide all the stuff that is needed to integrate into provide cloud backends iot cloud backends like the bosch iot suite but also of course the big cloud providers so that you can build the whole iot system easily by by using the stack and then add integrating the devices into the appropriate iot backends services so that's the software part we talk about also the infrastructure so we have the software development kit of course so everything you need to to build the software and to develop the software debuggers ide integrations documentation sample code whatever helps you to easily get into the the stack and make it usable for for you use case on the left hand side we have first the collaboration infrastructure and then infrastructure so everything continues integration services test base test centers all the stuff that is needed to run the project and to to execute yeah the project builds and the image creation and stuff like that and finally on the on the very left side security infrastructure this is tooling but also mechanisms for processes to ensure that you can build secure systems also that's needed to add security to your device that's basically then the the infrastructure part and of course there is there's also then the open source project so we have the os s community and something we want to build up and and maintain and and push forward and then again the working models within this community so the government structure the collaboration models so that it's easy for new intro interesting power interested parties to join the initiative and understand how it works and and can add value there and finally i mean such a distribution is of course nothing new there are also providers who do this but the idea here is to to have this this end user driven approach so it's a distribution that is driven by the using companies and of course we welcome engineering service providers because we don't want to build up all the the knowledge in-house we encourage service providers to to join the effort and to provide services in the ecosystem and but the goal here is to not have a render login at that point so we try to attract multiple such providers so that it's easy for for the end user for the using companies to choose the the engineering service provider they see best and or they like best and and and also be able to switch without changing the infrastructure without getting without losing all the the invest that is already in the system so in this picture i show you the the basically the the infrastructure and this is both the infrastructure for the external project but also the the the infrastructure used within the company so that's why some of the things here on the left hand side look weird when you look at an open source project but make sense if this is also used in-house so the core is here in the in the middle the the package repository so a repository of built components that can be used to create products and also of course the the storage of those products so the assembly of the components for a certain product and this is filled by the open-built service or which takes a multitude of input one are simply rooted through Debian packages which can be simply used as is they are updated and merged according to what happens in in the Debian source repositories but there will also be up there open source projects which are either not part of Debian because they are not fulfilling the purpose they have with with the components but also since Debian has a very conservative process and update strategy software that is for the use case embedded IoT devices needs a more frequent update so we would also manage such packages you know independent of the Debian part and and but in the same manner so we would use the same process the same package management process like Debian but would do this on our own in our own GitLab instance that is already existing for a purchase for example and of course there might be customer specific software and also binary only software that can be added to this this package repository these things are then of course not publicly visible they will be in parts that are private or even in private installations of those technologies within the company so that's how the packages are built and then when it comes to building then a firmware for an embedded device out of those packages there is then an assembly of the relevant packages and they are pushed through an image creator which creates the images and what is this image creator doing besides blocking all the stuff together it also optimizes the packages so it removes for example all the stuff that is not needed in an embedded device you know when you're using linux that it's of course very attractive to have for example all the documentation in place or man pages that help you in running a tool for example but those things do not make sense on an embedded device so this stuff will is removed during the image creation so that we get a minimal image that can then be flashed onto the boards that are relevant in the open the targets are standard reference evaluation boards that are then used to quality assure the the result in-house that could be also some more specific company specific evaluation boards but in the end it's the project board that's of interest for developers it's also possible to create images for virtual machines so that they can do some testing on their machine without having the hardware available and of course the image creator also creates stuff for for updating and here it's about images but we would not send of course the whole image but only a patch a delta so that only those parts of the device are sent that have to be changed in the end yeah and that's basically the technology the infrastructure behind and as i said the the idea is to have this in the open to have the quality assurance in the open and and all this stuff and the open source package repository in place but then you can use open stuff also in in a private manner but also have the local instance in your company to address then the product creation stuff another few on on the modularity so i mean of course we have packages and you can exchange all packages but this really important thing for for the whole thing is that it's modular and that you can that you can exchange whatever you'd like and this is what basically is shown here on this picture so the green parts are the reference system you see full and green are the parts that are provided by by the project and which you can use out of the box but of course you can exchange and remove whatever you like so you in this example here you have four different products which take only parts of of the whole thing even removing some stuff and even exchanging lower parts so you can also exchange the kernel in the bootloader if the one that is coming with the distribution does not suit you and on the other hand side you can also of course change the build system so you don't have to use this described image creation process for example if you are working in an in yachto based environment you could also use yachto as a base system as a build system and yeah step by step change your recipes to use the components of of a purchase or what the follow-up project of a purchase to have this industrial strength quality of the components or the appropriate meter data and and stuff like that which allows you then to to use at least this stuff out of the system so yeah we propose this so of course Bosch will be a driver for the whole thing but it's not our intention to to be there in a kind of master situation we would sponsor it of course in the beginning but the goal definitely is to to be one of many using companies which are shown on on on the top of this slide and in the end we don't want to be special here we want to be one of many it's an Linux foundation open source project so when you are used to Linux projects it would have been it would be standard so we would have the the steering and governance set up and there's already a proposal available which I will show in parts later on yeah and and it's basically then providing the package repository the the infrastructure and the working models to to the charter and all the stuff so the definition of how to collaborate but as I said earlier one one really really important thing is that the unique selling point of this is that we enable or we motivate a multitude of companies to support this and to support expert services to the using companies on on the top so it does not make sense to get into all the different details of of linux systems for for companies like Bosch it would be easier to have expert companies that where we can um yeah I get the information in a service contract stuff like that and yeah here we one thing on driver is of course to provide to prevent uh render login um but yeah um this we can only achieve if we make this as attractive to such companies um um that they are willing to to provide services here for example a purchase um is done in together with colabra um and I think colabra would also um yeah support us in in building this up but it's definitely not our intention that this is then only colabra supporting the whole initiative from the Bosch point of view of course I talked about the governance model and yeah if you know linux foundation projects this looks familiar to you so the idea is to have the the business and and budget side dealt with in a governing board to have also on the other hand side a more technical board the technical steering committee that is looking into the the collaboration with upstream into the different packages and then is discussing technical things architectural things the tooling and so on um and this is simply a best practice for open source projects to get the the commercial parts and the technical parts separated split it into two different boards we plan to have an outreach committee to market the whole initiative to communicate to go on events provide trainings so that it's easy to get on board into the thing and of course then the deep technical work will be done in working groups in technical working groups that are provided or that are executed within the context and again of course it's a model with with membership you can as you can imagine running such an infrastructure running the test systems the the services costs money and the idea is then to have to have a charter in the open source project a membership model on different levels and based on on your level of membership you will get more rights here in in those boards and committees on on the one hand side allowing to propose for example I will have influence on on reference boards and on on packages and all this stuff that's the one hand side so that's the commercial part so that we can run this and then make this a long lasting success story on the other hand side it's an open source project so everyone can contribute to to the projects to also to the package mechanisms and and all the stuff so there is no need to become member but in the end yeah we have to carry it in a way that it can last and it's a success a healthy project that has enough resources to to run the initiative so that's that's basically my proposal I'm coming to to a summary what we want to do is to control the complexity so the idea is simply we see this in-house so we have several business units which fight to get linux products onto the market and and we want to bring them together so to not invest redundantly in same in the same stuff and the idea is basically hey when we do this internally that is not really leveraging to the amount possible we can really get the lever when we do this as an open initiative let's get together and do the non-competitive parts together but also let's drive together innovation in this collaboration and and push linux for IoT devices forward the idea is to provide a collaboration infrastructure and to get industry strength packages that can be easily used out of the box without pains without additional processes needed that means on one hand side we want to enable maximal reuse so we want to provide basically everything that makes sense to be reused in this in this distribution on the other hand side you have absolute freedom to change whatever you like and also do this within the system so you can easily add packages you can easily change packages and maintain them still in the in the logic of the of the the infrastructure so that you don't lose the the management capabilities the lifecycle management capabilities but yeah can do whatever you need for your product to be successful component validation and reference hardware so we want to provide components that have proven to run in in a multitude of environments so that it's most likely that they also run in yours life cycle information life cycle management is very important so getting rid of all the pains with open source compliance with vulnerability management also providing stuff like export control information whatever you need to make yeah your your product ready for the market the thing is that in our belief this package-based approach so to to stay with packages until the image creation is really the key to keep the traceability throughout the product lifetime and and to provide long-term support to have identifiable stuff which is uniquely uniformly managed and being able yeah to to change it over time so that you can fulfill the the maintenance of your product throughout the lifetime and in the end what we want to provide prevent is really that you need to have a big bank switch so at some point you have perhaps bigger switches bigger changes but you should be able to make use of this and gain gain stuff by switching partially incrementally to to this logic behind behind the system and finally the project principles to to make them prominent in the end so reuse we want to be integrative and and we want to yeah provide available projects wherever possible so it's it's never that we will push something in this when there are open source projects available they will be available if this makes sense when we up contribute it's it's upstream first so we want to push it to the original open source project only if needed into the package management system and all the stuff simply because to prevent this maintenance hell of of having to patch software again and again modular you want to work in packages as building blocks and compose software systems of those so that's the modularity aspect by having the diversity so it's possible to change the components to the packages and to add packages wherever you need it it's a distributed development model of course you have to do this distributed because you have to support all the different parties collaborating here and we chose deliberately to use the Debian system here because this has proven over years that it's working in a large scale environment and we adapt this only were embedded aspects are required requiring to make the changes efficiency ideally you don't have lots of efforts or much effort using all this non-competitive stuff you can simply instantiate the base system and concentrate on your on your product specific parts that's the goal and yeah so it's for embedded devices so we think that embedded devices simply have lots of of special requirements and we want to have a free non-biased by by one company distribution that can be used to easily get embedded systems running so that's it that was that's what we plan that's our proposal and yeah as i stated in the beginning that is the gap we identified there are of course different systems like yokto like like the zip project who concentrate on on certain aspects but at least we didn't see that there is such an such a system such a logic in in the place to to really address the industrial concerns in using such a multitude of open source projects and that's the gap we identified and we want to solve and yeah my question to you basically is do you see this gap as well what's your experience with this just as an additional hint there will be a later on a panel session with basically the same title title where i will discuss with representatives from Colabra, Siemens, the Linux foundation and Bosch on yeah is this really an issue and does it make sense to to start this project so i'm really inviting you to also join us there in in this effort yeah to get more into and and also be able to phrase questions on yeah on on that topic i think now there is still some time so you can still ask more questions i will answer them and until the end of this session yeah and this means i'm at the end thank you very much for your attention and yeah looking forward to see you again hopefully in in the panel session and if you have questions please get them into the chat so that i can answer them thanks