 Hey, hello and good morning and good afternoon. Good evening to all of the attendees of the embedded Linux conference and thanks for joining us Today, I'm going to be introducing you to the concept of an old scenarios OS And the idea behind distributed operating systems that does not rely on the clouds as the need to connect Devices and have them cooperate rather builds cooperation and Interconnectivity between IOT edge devices at the edge itself Before we start Just don't get too attached to the old scenarios OS nickname It is temporary. It has served us very well, but it will soon be Obsoleted The new project name will be announced during the eclipse conference 2021 which is going to take place at the end of October between October 25 and 28 You guys are more than encouraged and welcome to join us more information about The technology the projects the partners the members the name the branding the logos Would be all disclosed at the eclipse conference What we will disclose at the eclipse conference is a follow-up to the recent announcement of the cooperation and collaboration between The eclipse foundation in the open out of foundation this corporation Is about the nurturing fostering and creation of a global ecosystem For the promotion of the open-armony brand and open-armony technology So more again at the eclipse foundation joined me and all of the Partners in this project and you'll hear more So let's start from from a problem statement if you look at IOT and IOT The way that it's built today Surely you cannot say that it's built in an intelligent way although It's supposed to be it is actually rather dumb if you look at the devices that populate your household or The wearables on your body or devices in your car It is very easy to witness technological fragmentation. They behave differently They're powered by different technologies that connect Differently to the cloud by a different applications. They have installed Onto your smartphones, they most of them all have a gateway that they rely upon to connect the cloud So so clearly They do rely on intelligence to build somewhere else technology that they're built with does not allow cooperation among devices itself and then when you look at the Operating systems for instance that is used but any kind of technology inside those devices It looks like device makers are trying to reinvent the wheel all the time all over again This really leads to lack of interoperability at the edge between devices Wherever or whereas you have such interoperability presence in some shape or form it is really brand centric So devices of the same manufacturer brands They can partially interoperate one with each other, but as soon as you try to combine devices from different makers Then there's no chance that they will work together As mentioned before the whole idea is that IOT today is cloud centric So compute interoperability leads in the cloud and it is evidence. What is the business reason behind? This design and architecture IOT is driven mostly entirely by investment capital and RNG from cloud providers They care about data being driven in the cloud where data can be monetized It's about selling cloud type of services whether it's storage computes Analysis of data monetization of data of users devices and so forth And so the business model Drives data to the cloud and it's no mystery that The overall architecture is cloud centric an architecture for IOT that is cloud centric poses Many issues not only that of reliability on network connectivity So that devices always have to be connected to the cloud if you want them to cooperate or do something a bit smarter but also these architecture is hugely inefficient Certainly insecure it drives data up and down from the cloud It opens a lot of connections from your households to which is a subnetwork private network to the internet And certainly it is expensive because the amount of data that you need to drive through your connection Whether it's fiber DSL or whatever it's really Bigger than You know, it would be if cooperation were to be a corporation was to be achieved At the edge or at least a hybrid model where the cloud is one of the nodes and one of the possible compute is not the king That proceeds data from all devices nor the endpoint Okay, so these are problems that we explore today in the way that IOT is architecture and I think all together they form Problem statements Now if I look at the three main if you want personas targets beneficiaries of the IOT You really have three consumers all of us the vice makers Also known as OEMs and content creators So in the current IOT design and architecture if you look at consumer We are all exposed to unnecessary complexity and security lack of privacy And effectively this cloud-centric IOT Whose objective is that to drive as much data as possible Into cloud providers data center Monetizing that data has turned us into the product. This is social media Yet again, if you want a social media 3.0 If you look at device makers, they stated revents the wheel all the time consumer devices are Supposed to be changed often and and there's huge time to market pressure on Device makers so choices that are made are suboptimal in reinventing the wheel. So Operating systems are most of the time not optimized to come with the chips that the device maker chooses Certainly security is not core at centers. I mean, we're all aware of devices IOT devices out there with no password for the root account or default password. These are just examples of Of of suboptimal choices. It's about speed In time to market. It's not about longevity or long-term viability of a consumer device In this process more than a device maker or original equipment manufacturers who can think of device dealers They really deal devices as fast as possible to us consumer so that in the process they can help in the Overall business goal of monetizing consumer data now most of the money for this monetization is actually ends up in the pockets of the cloud providers a device maker really Can have access to a fraction of the overall available business and fortunately, this is You know, this contributes to the fact that They're really behaving as device dealer For a fraction of the available money In content creators, ultimately ultimately they have a lack of choice in terms of which devices they can choose Of course, they would choose the type of device and the brand of devices that grant them the broadest addressable markets like standards For interoperability of applications across different operating systems across different devices and across different brands They do drive cloud stickiness. So the choice of a content creator of a famous applications of which os Brands to support will drive stickiness to the cloud services of that provider The available content does influence greatly device makers choice With regard to the operating system that they would use for their devices If an applications is on the poor side of applications are available on a given os Then device makers that ultimately wants to sell their devices to consumer That ultimately are driven by available application will be somehow forced to choose The os that has the largest market of applications and and content creators to In the end are upon On the chessboard of of this top-down cloud-centric IoT that Monetizes consumer data So if we take a look at the household internal devices We can really map things in three categories and I think Assessing and mapping out Different devices into different categories can help us to figure out if it's possible to try to address the problem of today's IoT And try to build something that is better architected in the builds cooperation and intelligence at the edge And work with the cloud as opposed to working for the cloud so First devices in the first category of devices that we can think of as smart things Think about your home. You can think about smart lights motion sensors smart door locks thermostats radiators valves cameras doorbells alarms smart TVs projectors speakers smart wearables Indeed smart things are really sensors and actuators. Most of them are built with smaller MCUs They run mostly Arktosis such as free our tosses effort light to us richer one and linux But really these sensors and actuators are mostly built out of MCUs Their footprints goes from kilobytes to In the lower gigabytes or hundreds of megabytes They come with or without display and when they come to display You can think of symbol graphics for touch control panel or keypods in the house from managing alarms or cameras and so forth They are enabled with close-range communication. They're supposed to communicate one with each other mostly With the gateway inside the household. So we're talking about tens or maybe hundreds of meters The protocols that are used are usually zikbi or bluetooth and you know bluetooth And the applications are designed and coded in cc++ c++ javascript At times java although that is resource consume Okay, so these are the things sensors and actuators small devices with real-time operating system or micro os's on board Second category so you can think of is the category of gateways gateways are necessary because they do provide a mean For communication between things so things to things or things to cloud comms. They do provide access to the internet outside or the household You You can think of probably you've gone through this process anytime you buy a kit of valves Door locks cameras they come with their own gateway So gateways are specific to the brand of smart things that you purchase and typically you you need a brand specific gateway to connect The things of that branch to cloud through through the gateway itself They do have the ability to provide compute storage They serve as the entry point for over-the-air updates Uh When it comes to updating devices in the household, uh, it is usually obtained Either by a smartphone or a gateway Gateways in the household are powered by cpu's. Uh, they're typically Designed with linux or more the headless devices no graphics footprints in gigabytes in the range of connectivity is certainly Larger broader than that of smart things gateways Develop develop deploy a wi-fi internet As well as it be a bluetooth for communicating with smart things. So can enable communication to medium range As opposed to smart things there close range Build devices The third category is that of smart mobile You could think of phone tablets tv's although tv's don't move, but you know, you think of tv's is a big smart mobile device They are used for smart things configurations. Uh, they're, uh They do have a brand specific smart things applications On a given tv They can provide compute storage hmi And they can be used for training Uh Smart things you can think about the way that you do train your smart house and smart home routines today Typically you take your phone or tablets and then you train devices to do something interesting inside the house And you would do that by connecting those devices to a cloud and then connect, you know using technology and applications such as if then that else ifttt Then that then that or is this than that? Uh, if so that you can connect different clouds, uh applications one with each other and you know, but usually use a phone or mobile device to obtain that These are certainly the richest devices smart devices out there multiple cpu's gigabytes of storage and footprint They come with linux on board accelerated graphics and rich displays And they can provide Medium-to-long range communication. They connect by wi-fi ethernet inside the house cellular towers When you're moving Okay, so these are really the three categories that you can think of uh, if you want to map out devices In the iot consumer electronics world and when we restrict this to the household If you want to put it all together Try to make some sense You can think of of the device type at the bottom of this table I don't expect you guys to read into this which is bear with me, right? So you have all device types and then you have the three categories of things gateways and mobile And then you have the device performance up here, right device performance in terms of range of communication Power consumptions memory footprint process or speed really drives the choice of the Operating system that you use whether it's a micro os Or linux for richer devices whether it's powered by an mcu or a cpu Whether it is powered by one or two mcu's or a combination of cpu's cpu's or multiple for cpu's And this device is of course can be headless or have a display with simple graphics or accelerated graphics with Applications that typically are designed uses cc plus plus javascript java depending on The os and the footprint available If you move up then You see that for Devices that are richer mobile you start having application services such as mobs locations and phones And then when you move to Functionalities that you can map to each devices and categories such as things gators and mobile Their role in in in an edge distributed Scenario Such as the role of an actuator the role of sensors all of devices provide distributed sensors Some of them provide actuators whether it's a touch display the ability to open a door Regular temperature in the house hmi And if you look at the right side of this Chart when you start looking at gateways and mobile these are richer devices that can provide distributed computing storage And and and if you think about ai They can be orchestrator of an intelligence agency Where sensors and smaller devices can be only agents available to do something But not really having enough computing storage to be able to coordinate Other devices Okay, so this is an attempt to try to map different devices with their physical features characteristics that drives the os choice based on footprint and they Ultimately drive their role Inside a distributed intelligent agency, right? So the objective is that to different means somehow the industry build once the technology share build A framework through which devices can cooperate and collaborate At the edge the closest the possible to us So if you think about the old scenarios os that we're building in in The projects that the clearest foundation will will host um after having seen the iot problem statements and have you try to map Everything out. I think we can come to a mission statement So a project an old scenario os that has to drive defragmentation in the iot consumer industry In order to build distribute it intelligence at the edge It has to come as open source project. So open source technology that alone is not enough you need to add to that open governance Hence the choice of of open source foundation that can be the arbiter the moderator and grant neutral ground for industry partners to cooperate Uh as they build the technology that they will adopt And which in turn will drive less fragmentation and more cooperation So I talked about industry partners. So a project like this has to be industry driven So the vice makers cpu vendors content creator. They had to collaborate To develop the technology they will adopt in their real life products The more members participate the more interoperable and cross-brand this project will be Uh user has to be uh core and center We've seen the dystopia and the problems with the current architecture and implementation of iot that sees users data becoming the The business drivers and users becoming the products of the entire iot architecture So users user experience private and security that had to be core and center They become pillars of whatever we end up building in such project And then as said the ultimate the ultimate goal is that to After we have defragmented and we have real product in the market with this technology on board To distribute as much as possible The intelligence at the edge And again the cloud as I said before becomes just a citizen in this Kingdom and it's not the king right in the in the realm Of iot There's no room for king all devices are created equal And they operate and interoperate electing from time to time Who's best fit to be a coordinator or orchestrator of iot devices And I think it's worth starting from this letter point So when we think about edge devices collaboration The role of an open source project is not to reinvent the wheel as a matter of fact is the opposite Someone has a problem chances are somebody else already had it So why reinventing the wheel in terms of building new technology? So there has been extensive research if you look at the w3c around distributed agency and turning the web Into a semantic entity that independent autonomous agent can browse Uh, so the idea is that to leverage existing works And research and implementation done by w3c as well as itrepoly Along distributed agents and how it worked and how they work And and think of smart iot devices as belonging to what we call a distributed agency So in a distributed agency Think of a device as an agent Each device in each agent of course has different physical characteristics Agents play a different role in different scenarios An agent can do something in a specific scenario and can be used to do something else in another scenario So they become multi-purpose and of course The richer the device The more flexible and the more feature this device is equipped with at the more It can be repurposed depending on the different scenario to act in different roles and capacities Agents do broadcast their characteristics at the time of agency Bootstrap, otherwise, uh, there's no way to know what a device is capable of doing And since you have many devices in the house, uh, or in any agency Agents do elect their agency coordinator with potentially a backup and the reason why you do that It is because there's agents that are better suited to coordinate others. They're equipped with more compute more storage They can do pattern matching between problem and the set of features of the agents that belong to the agency and then decide which agents to select For the resolution of a given issue slash routine And that's what coordinators the trigger coordinated execution recruit available agents and boot time Effectively just look around based on what's being broadcasted and adds to the agency the agents available And then distribute the tasks whenever there's a problem to be Resolved in a core core cognitive matter Operatively then coordinators will select the available agents that fits The needed features that are required and then trigger a distributed execution So, uh, how do we describe devices characteristics or problems or tasks or routines? If we look at the word done by w3c, uh, there is a concept and the concept of ontology that is used to describe the world around us and since w3c's Is coming from uh markup languages html xml and so forth The language that w3c has elected for this is called ontology web language, which is based on xml and rdf So, uh, and we'll see an example of what an ontology is So if we use ontologies, uh, let's think of that as as small databases if you will, uh, that are Written in code in human readable language ontology web language Right. So an agency coordinator has a description of device characteristics as well as problems Uh, using the same language and the same notation semantic and syntax And so an agency coordinator would matches the agent ontologies with problems ontologies try to find if there is a match Between the problem that needs to be solved and the available features of the agency And and if there is a match the, uh, coordinator selects the agents distribute the tasks and executes The agency training is supervised or unsupervised meaning that We human can tell the coordinator what type of routines We want the agency to execute and if there's uh enough available agents with the necessary features to fulfill that routine Then the coordinator will execute Or unsupervised meaning there is more knowledge that is built by the agency itself as the agency executes There is new data, new rules, uh, that are found and so unsupervised Knowledge is built and that unsupervised knowledge builds routines that the user Did not initially thought of Okay, think about you know I've seen that you turn off the lights every day as this time of the day And as soon as you've done it you lock the door and arm your alarm you know that could be unsupervised knowledge that emerges by Observing patterns repetitive patterns that That the user go through on a daily basis and the coordinator can observe all that And propose new routines and and in tasks Okay, this is an example of an ontology. I'm not going to spend too much time on this on the right sides of the slide. You see A typical xml markup notation With ontology web language, which is based on rdf And this is an ontology that describes a lion Actually an african lion being a lion and being a lion and animal So you can see it's a typical location that is used for relationship between objects in a database And yeah, and so you have effectively classes and and And then you have instances and an instance is the actual objects that belong to a class with Those features and physical features in a real life scenario Okay, so there's the theory class often relationship between classes and then instances and objects That are real life instances instantiations of classes Okay, so this is what is used by w3c for description of problems descriptions of the real world as we know it and then pattern matching and And uh autonomous agents, uh intelligence okay, so, uh We now know a bit more about what, uh type of technology and what kind of research Is going to be at the base of uh distributed cooperative Work between objects powered by In all scenarios os So just submit it all up autonomous agents in a household are things Uh, they provide sensors actuators and compute gateways. They provide compute stories communications and they can Act as coordinators The good thing about gateway is that they don't move like mobile phones mobile phones as As much compute if not even more than a gateway, but they tend to follow us Uh, when we move outside of the house So gateways are uh physical devices that are permanent inside of households And they have enough computing storage to act as coordinator And they mobile a compute storage. They provide compute storage hmi for training Uh the agency in a supervised manner And and they can also provide coordination to say it's not ideal, but it can easily be there as a backup Okay, so and uh if you remember this light, uh They should, uh Provide some context and additional information Uh around uh distributed communication distributed agency and how to achieve distributed functionality Between iot devices and the edge. This is just one of the possible directions that that research Uh of this project can take and that implementation is taking, uh, but you know, this is uh This is what we're looking at right now Okay, so back to how we're building this uh old scenarios os. I said before it's about building Differentment in the iot consumer industry and being able to build From the same source codes, uh The os image for different devices, whether those devices are door locks cameras Thermostats TVs and so forth, right? So, uh in the industry there is, uh, I would say the industry standard project that supports Building os image from available Lego blocks and this project is the after project. So, uh, we have, uh, leveraged The after projects technology and architecture to To create one pristine source code for the project from which through a bit bake in the after project infrastructure You can now build in os image for any of the iot devices. The idea is that if I standardize on technology tools version of linux kernels zephyr ferritas lightOS Middleware available through layers and raccps effectively I provide industry players with a very convenient way to a Do not not reinvent the wheel be standardized on version of software components and at the same time I can automate, uh, testing, uh of the os images and reduce custom maintenance and Because you know, you adopt the same version of a given component whether that's eleno kernel or the true chain or zephyr So on the left side, you see some of the relevant layers, uh META open harmonies or boot layer, uh, META open embedded is another important layer that we use META C-Lang META zephyr META free RTOS META lightOS For the RTOS is that we support for mcu-based iot devices META risk five Then open harmony components from the open atom foundations are a package in their META open harmony layer And then you have harder specific and device specific layers such as META seco A META st micro META evenger 96 META intel, yeah, yeah, yeah Okay, so in short, uh, the goal of the project is that to uh standardize on technology and tools and provide industry players with A very convenient way to create as many os images as possible starting from the same starting point And the opera project In big big gives us all that um We have the concept of a build flavor a build flavor effectively. So think about it It's nobody has ever tried to Leverage one build infrastructure and to build different type of kernels inside an OS image So we had to move away from more extents or go broader or higher than the idea of a supported harder Uh, and we needed to create something that is sort of a combination or the tuple between an RTOS slash kernel And the supported hardware and we had created the idea of a flavor So the flavors are a combination between The kernel and hardware. So the currently supported flavors are Or kernels are zephyr linux and then work in progress light west and free our toss And the images that we build Are headless as well as rich images for linux and running on QMU x86 and 64 arm arm 64 As well as Similarly for zephyr For QMU x86 cortex m And then you see there a list of reference boards that we Have tested and we're building the Dois image for from 96 boards avenger 96 par by st micro Cortex a to nxb imx8 from seiko raspberry pi as maker board for model b arduino nano 33 b lea and really sense For cortex and based devices par by zephyr nordic semiconductor 52 a 40 development kit as well as the avenger 96 uh cortex m part in the nitrogen 96 boards, which again is par by I think mordex silicon. All right, so you see here the flavors when you move into bigger devices and richer devices It's about linux and it's about cortex a it's about intel. It's about risk five And then when you move into mcu's as one of the devices about zephyr. It's about cortex m It's about arduino As a as maker board as opposed to raspberry pi for illegal space devices Uh, we also have created the concept of the blueprint. So the objective of the project is that to create reference images for devices, so whether it's a door lock a gateway, uh camera, uh mobile phone or smart tv, uh the objective the goal is that to Uh, go all the way to 80 percent production ready reference solutions So if i'm a device maker or a maker, I can follow the instructions for a tested blueprint And then those instructions will lead me to say from raspberry pi or arduino With the instructions on how to wire what kind of uh displayed by what kind of uh sensors and actuators to put together Will lead me to create an 80 percent ready door lock or 80 percent ready smart tv 80 percent ready gateway And this means that if i'm a maker, I have all the way of means and tools to experiments and then if i'm a device maker or oem Effectively i'm 80 percent done. I just need to take this optimized package properly branded focus my value add on top And and then go to market. So this is supposed to effectively Uh provide a mean to different in the market by providing Almost ready reference solution. Why would appeal something different if I have an 80 percent ready door lock or blueprint available But also accelerate time to market of the members who participate Okay, so for our first release which should be released to market by the end of 2021 Uh, the available footprints are door locks, transparent gateways and touch panel the work in progress are smart vending machines mobile phones smart speakers with vocal assistants robotic companions and so forth many more to come uh, taking a look at security, uh, we have, uh, Made some design decisions. We're not going to go through this extensively When it comes to security hardening of the linux kernel as well as related layers, uh, the bringing security components There's more on, uh, the dock page But effectively if you look at the linux kernel hardening options, we work on memory allocators We have disabled, uh obsolete features such as compact brk k core and bean fmt nisk We have compiler enable compile lever hardening by the 45 source disabled physical memory access In order to detect and save memory permissions With art and user copy from a user space, uh enable kernel structures data validation And we're now considering whether or not to enable alia and a new panic On ops All of the decisions that we take when it comes to enabling security features in kernel have to take in account the bulk ability the ability to develop this software And whether you know or both productions because some of these features will of course slow down development as well as footprints And and in performance of of the system. So it's always a trade-off between Introducing more security and slowing the system down And then we're taking components from meta security security compliance meta security as a firmware and meta tpm So if you want to think about the high level architecture, uh, this is similar to the slide that you've seen before But you can think of the world divided into mcu's and cpu's mcu's on the bottom side cpu's Right side cortex m See then in cortex a intel respire and so forth You know, but a unified bootloader interfaces The idea is that whether you boot from an ncu's or cpu when you had to do ota Um and reach the system Regardless of the fact that around linux or zephyr on top you had to build something which is somehow unified there This is where you have security functionalities that are specific to the bootloader Uh, and then you can have an os level ota if you need to Ota our kernel the sits on top and then if you take the left Turn as opposed to the right turn if you go left you have Micro os's and our toss such as zephyr light os free our toss if you go right you have linux So sort of abstraction layer for portability of unified system services You can think about you know, uh enabling those system services across iot devices to enable distributed communication Or broadcasting of their functionality that those unified system services somehow have to leverage Uh an abstraction layer, uh, that is abstracted from the implementation of the underlying kernel And then if you have taken the Turn to writes and you find yourself in the linux land Then there's of course leading to the space and packages there with linux specific ota To upgrade packages or containers And depending on the strategy that you use and you move up you have application debuggers c2 profiler memory profilers He's called tracers and so forth. These are very useful as you build your os image application runtime framework And that can be javascript cc plus plus java bay is depending on the resources available in your devices And then application services the moment that you start moving toward mobile phones mad locations camera dosing for more Rich devices such as mobile phones tablets and so forth on top of everything if you manage to Somehow equip devices with similar technology Then you can think of enabling now there's a concept of the autonomous agency that i've explained you Some minutes ago, so distributed communication in rpc ontologies to describe problems and devices agency coordinator elective algorithms and Ultimately a distributed inferential engine for the distribution of tasks across devices That together with training mechanism whether it's supervised or unsupervised That is the architecture that the project is going for As you can see there's a lot of technology we can leverage here and there. I'm sure that your brain is already racing Toward thinking which Existing project or technology can be leveraged to fulfill the specific part of the architecture And that's exactly the approach that we're following try not to reinvent anything from scratch unless it's absolutely necessary Try to leverage as much as possible what exists out there that preserve industry investment. It's about Real product and industry members participation. So we don't want to Um Waste their existing industry investment on os's and and cpu's as in other open source projects We want to leverage as much as possible the investment. They already do so that we can build this out of existing Uh investment as opposed to requesting industry members to drop what they're doing just to do something super new from scratch All right, so the project His uh, of course runs on public clouds to enable corporations between members as well as community access We do have a ci in place that leveraged git lab runners for build With a git repo cache and big big estate null cache to speed up the build Jobs are placed strategically across repository to ease maintenance We do use lava for small testing on hardware and in virtual environment when it comes to ip compliance It's can code physiology reuse. They've been mature Are all git lab runners to run so automatically anytime we merge Any piece of code in there we do run our ip compliance to change So that we are always on top of our Bill of materials after bill of material Built which we require As a must have requirement before we release any official release to work Uh We have shared jobs, uh That you know You now know the idea behind the flavor of machine, but the shared jobs effectively are triggered anytime we need to build any of the officially supported machine Uh, we have 14 currently the bill linux effort for your toss and the blueprints We also have hidden jobs. Uh, the hidden jobs are effectively think of the building legos The shared jobs leverages to actually Build the final images. So we have hidden jobs for creating the workspace Hidden job for initializing bitbay And then we have hidden jobs for building basically inux image set for free or toss or like to ask Jobs for building recipes and building the final image build documentation Trigger lava test obtaining a lava report and trigger in ip scan a set device testing Leverages lava from linaro. Uh, it is designed to be decentralized and distributed So that each member and contributor can add physical devices at different locations Devices are added under testing and can be shared by a public cloud infrastructure The idea is that each side can add one to a hundred other devices and they all become available To the project without having one central location or real estate where you have to have all devices physically installed Uh, we use linaro automation and validation architecture and the Hidden job lava test calls lava create a testing job in lava report Uh, runner iterates through all of the active lava test jobs collect results aggregates them in a report that we can then Look at and you have an example of a report Uh, it says the uh, initially, uh, the eclipse foundation Has announced collaborations with the open atom foundation to promote one ecosystem for open harmony devices And so the questions that everybody has is how do you ensure the two foundations first time in history can work together so that if they build A device in europe and a salad to china Existing applications running in china built by content creators in china can then just be Dropped on top of that equipment built in europe and everything works. It's just super simplified example we do Ensure that by defining what we call open harmony application compatibility We define the compatibility in a compatibility specification and we automate check That devices fill such compatibility specification by an application compatibility test suite Uh, which of course, uh, is included. Uh, and is part of our ci testing for our Building uh runners so that anytime we actually, you know build an image Uh, we run the acps job to verify that none of the application compatibility requirements Is somehow broken Um We select Open harmony components. So the specification and the uh compatibility test suite effectively drives which components Are required from the project to achieve compatibility Uh, and those are packaged in their own layer And so as the specification evolves the necessary components to achieve Compatibility will be developed as a reference implementation And of course the project encourage Uh members to use Reference implementations of such components for say application services But nothing prevents the members to create their own implementations so long as you are compatible with the apis And the compatibility specification than the golden And as part of this some of the components that we needed to integrate, uh, we're, uh Use used gn classes and ninja files for Uh, uh compilation So we did develop a gn class a big class for big bake So that we need to build gn slash ninja files Using big bake and that was a functionality that was lacking from big bake. And so now we have that available And uh, it's going to be contributed back to the opto run Uh, two words about ip compliance as I said before we have a hidden Runner job that anytime there's a merge Does trigger nip scan the leverage scan code phasology reuse from free software foundation to generate the Bill of material in an automatic fashion And then we do have an ip audits team That reviewed this low resolution software bill of material Looks at false positive false negatives and does the necessary work to give us the most accurate possible bill of material before an official release We do release bill of materials for alpha, betas and official really releases And the ip compliance to chain continues to chain that we have helps us uh To actually keep up with the amount of code that is developed and new features that are integrated as well as having this A bill of material software bill of material that grows over time um Yeah, and so that is The flowchart so as you can very quickly It's all based on yacht a bit big We look at the recipes and images that are built We look at the packages from the recipes that are pulled in We do use something which is called azure's aliens for friend or debian's matcher The idea is that instead of just going through all different packages all the time We can probably trust some other os's out there that do the same To come up with a better idea Of or an initial idea Of what the license associated to that package or set of files could be In the general goal is that to come with out of the low resolution automatic scanning with a more trusted response from the system so that the ip audit can seem has less to audit And and it's effectively less labor intensive activity Uh Just to go through packages and licenses that are very well known Because they are matched or come from or similar from Another project such as debian that does a fantastic job when it comes to license complaints And and yeah, so the tools that we use are so this can't go to phosology phosology is where the work of cleaning and clearing up false positive and negatives happens And uh, yeah, this is where the audit team does most spend most of their time kudos to them because they live in their phosology uh Hell on a daily basis And then uh, ultimately the bill of material is generated and this nice dashboard that you can see here on the left Use our team, but as well as all the board members of the project and idea of how many licenses type of licenses incompatibility How much work we still need to to do for all of these supportive licenses we have Okay, this is how we keep up with license compliance Uh, the idea behind maintenance and release lifecycle, uh, is that we're going to have one major yearly release every 12 months and a 30 year lts Based on bug processes and cv e process with a dedicated lts team But when i'm sure that if i'm a device maker, uh, I have an open source project That gives me something that raise the bar of maintaining software inside consumer and iot devices So that I don't necessarily have to staff my own maintenance team, but that can be an incremental investment on top of it And so we're setting the bar very high at the project level So that lts is part of the investment that we do Uh, uh inside the project and it's a shared investment across Participants members and of course we try to align as much as possible with components, whether it's linux tool chains zephyr Uh, you name it that already has an lts so that we can leverage all of the lts work and see the fixes and bug fixes that are coming out of that lts stream And so this is how it should look like, right? Let's think about, you know, uh three releases for the next three years is called just mean goofy and daisy Uh, you have developments that last one year when you go in lts You're one you're two you're three and then at the bottom of this page You see that the bug in cvs policy Has a decreasing sla as you move farther away from the release dates Of a given release. So we focus on more important cvss scores cvs as well as critical bugs the third year and we you know We try to fix everything that we could possibly fix in the first year, which is the era of adoption of Uh, the operating system from device makers One works about standards and compliance. So as said, it's all about reuse It's all about leveraging existing investments and building on existing compatibility standards So open harmony is for application Compatibilities, we name that we aim at achieving out the project compatibility when it comes to layers and the way that we build layers The big big builds together open chain when it comes to license compliant spdx reuse when it comes to Using reuse software for free software foundation and arm system ready for security Project phases and we're almost done Bootstrap, which is where we are right now 12 to 18 months new brand hosting foundation and growing active members design winsome community Defragmentation of the industry 12 to 13 six months This is where we need to sustain industry participation and gain members and design wins Design wins are real proud of the go-to market. You can think of this phase kicking in 18 months from now We shift devices applications and consensus market effectively you can go to your best buy or media world or fnuk and then see devices with a Compatibility stamp on it and if you buy those devices, you know that they will work together because the share the same software They've been designed for user privacy and security mine and they have been designed and they have been designed to collaborate as much as possible aph and Yeah, and then and more devices will collaborate more use cases We will enable and and ideally we can turn this around and have a More user centric and less cloud centric iot in 18 months from now No cat so and this was it So I just wanted to thank you and I would be available for questions Uh, this is uh, my team the open source technology team at Huawei. My name is davide richie and uh, yeah These are the partners. So big thanks to linaro seiko arrays in the stuja noita park and the eclipse foundation Come talk to us in our matter most channels. Can the qr code there? face away so you can scan this And register for eclipse con 2021 where you will hear more about the brand the partners more partners as well as having dedicated Tracks and talks for the technologies that I've very briefly presented to you today More and more in depth will be Sad at the eclipse conference 2021 with that. Bye. Thanks