 Welcome to one of the last sessions in this room today, I Hope you are not too tired for this last session Let's start with Some reports of our experience with the so-named separate downstream development We Have made in the last couple of years some experience to work with safer in product development and we that is to be us and me Stefan we come from different companies that bought surprise We work together for a couple of years to make some medical devices and also connected health systems together with yokto or several technologies and so all what you see here in this slides is more an Example of best practice we have learned to work with these technologies and at least this is a theme of really about the several in environment and so as a result of this we create a project on GitHub that has some public access or where you can see all the learnings We see here And then public environment. That's the name bridle and so We to be as and me. We are the maintenance behind this small project And what it is we will learn today in this session on the end With all our experience we know in the face of that we can made some trainings on our customer side in-house trainings online and That's our thought for the community Try to integrate several technology into medical devices So let me start with a short story I Think a story of Your life with several or in the future When you come the first time in contact with several You see oh cool thing. Let me play with it and all of all is start with a documentation and learn what several is and What are the pieces of several to create Start to create your own experience to create your ideas and Some time later you come to conclusion. Oh, it's a cool thing But on the end I have made many many changes on the source code base You will have new apps new drivers new boards maybe new tools whatever subsystems and libraries or You need in-house or to create your product and then leads exactly to the old pattern you have made a fork of several and To protect your product development for the future It's not the ideal Situation on this point and you are looking for any kind that's bind all these things together I have named it your kite line and What you need on a really kite is on the end Any point where you bind all together? That's the reason why we name bridal this project and On the end what bridal will be for you Is an example? Exactly a separate downstream development example Where you can learn? What is the best practice or what is the thing? You will need at least to start your product development in a professional environment So the background to come to this conclusion Was Was a story we have hold in a talk on Tuesday To be as had a Talk about how I feel love in self fall in love with suffer and There is one important conclusion in this talk That when you start a professional product development with open source components You will need more architectural efforts Beside your system architecture That means you need any environment or infrastructure for knowledge base management and also for the collaboration management and Let me sort this three parts a little bit in a other order What we have made with bridal was to start with a collaboration side You will see in this talk Some ideas and best practice how to come to a calibration with the community or with other parts in your product development contributors or customers and customers and That leads on the end to a Really really fancy project logistic on github that explain the loosely coupling from your downstream environment to the upstream the environment to suffer and Also, you can see then on the end that this is a tool for you to create your own life cycle or release management and And For the architectural perspective that is exactly this point where you create your qa environment to fulfill any kind of Regulation efforts or requirements Here for example the norm from the medical environment and The second point is the knowledge base management You will see an idea How you can create more than only a single document from the suffer environment you will Create your own code base. You will create your own product and Application and so that have to document in the same manner as sufferers do and so we have a Best practice Integrate that split your documents into different perspectives That's the beginning today and that can be Extended to any kind of perspectives for any kind of domains for example test environments test reports test specifications or Here reflected to the architectural environment the traceability and Yes, on the end you will create your system your product so you need a system architecture level and That is the most important effort made by the suffer community That you are will be able to create such kind of downstream development that you found the exit or Entry points to extend the framework itself the tooling the tool environment provided by suffer and also the code base so Let me start with a little bit of history where we come with this example project Yes, we have made some projects for the medical environment and Anytime in 2020 We have the first contact with the Nordic SDK environment and Nordic has made exactly that what we have missed and so We start to extract exactly that point that is important for our product development And also what we can split out to provide and template and blueprint for the community That was the idea and in spring 2021 we have a first prototype of the product of our project and In summer We was on the point that we need more collaboration environment to work with students for teaching or with other companies in the same level for product preparation and so it creates this virtual company the Tyak systems and integrate all our ideas under this organization on github and when you are looking for in github on user links in this Slides online, then you will land on exactly this point where you can see what we've done in the last two years On the end where we are today We are happy to say that our bridal project is exactly on the same Release point where suffer is we have not introduced any kind of new versioning That is The reason is the better orientation for external partners where we are and so In the time being until today We create some more documentations our over our development model and contribution workflow so that potential contributors have an orientation or where you where they can ask What to do to help us or? us together and on the Latest version we have start some feasibilities That is a really important thing. We can talk maybe have a talk in the on the next conference next year to integrate an Architectural model to use more and more the device tree abstraction to create System models so that we can change hardware components Protester boards and so on that is more the idea that Tobias has talked on Tuesday, so you should have a look on these slides and then later Have a look on the documentation in our vital project a project so that you can have an entry point for the abstraction So on the end, let me start with the project logistic we know we need any kind of collaboration tool and Over the years on the end we come to this conclusion Where you can see on the orientation for you Some important workers github workers In the middle is one and on the upper side is one the upper side one is the first point where we can Sure that we are loosely decoupled from several But important is loosely we have an Synchronization of our own mirror only every two hours or boat and When we see we need some quick changes on the code base of several This worker makes our rebasing automatically and when this will fail We got emails that we have to do some manually. So that is important because several is a dynamic project and It grows up with new ideas and we will capture all these new ideas in our own product development and so we can Be safe that we catch this or But on some points we need some proof force changes or we need some Backports or we need some Reductions of test fixtures whatever and the second really important task Here in this diagram is our bridal worker that's on the end as a west workspace every time when we made our own pull requests and also it's a nightly protection or All the major releases we will maintenance I Will run every night with Qa tests the Qa tests are reduced of a minimum It's a virtual project, but on the end we have created the infrastructure. We would need an and exactly We would need exactly in a product environment. You see on this side We have a self-hosted a github action runner On a Raspberry Pi with real hardware on it our own reference system the Tirec McPie and every night we run the architectural tests suite for arm and So we see oh the basic is good enough that we can go on and On the other side is a really important thing. We see soon in the next slides That's our documentation store And this documentation store Will be provided with each pull request or Major releases with new artifacts assorted by versions so that a doc set from of different documents Will be holds also for the history for each past versions Quick look on our hardware in the loop. That's real Exactly the next gen we work on a improvement on this the current is too slow To work exactly on every pull request and In a good power that we can make more test suites inside so Here you have only an impression of what is possible On the end and that depends exactly on your product environment Hit the Maker boards on the upper side and place in mind your own product on this point and you have a hardware in the loop We create until the next year new Definitions that we can use modern systems like lab grid to integrate Scaled hardware environment to the github environment and The other slot was our deployment environment for the Websites for the documentation That's a decoupled system complete decoupled system from the github environment It's a standalone web server within monitor the monitor will Instrumented by the pipeline from github itself and sort in exactly the right Position your documentation you have made on the github side Yes, we have learned in all other sessions that You need a rest manifest For such kind of development That's only a short impression What bridle Gives you bridle comes with its own vest Manifest and Please have a look on the online slides. There are some more detail information What you can do? but on the end our own manifest Declare us your software structure so software configuration management is fulfilled with this and on the end of this is your build environment on the local place and also on the CI pipelines and The second important thing is bridle is a suffer module It's the same situation for other downstream developments and in this Module description we have added as much as possible entries so that you That we can Evaluate all the situation or the best practice We need to create Product with all the features that suffer provides Some words to the document sets We need it for our own for the knowledge base management and This document set online Provides you with some features you will not see exactly on the suffer documentation side It starts with the different sets You see here you have a completely coupled Documentation for the suffer content itself that is this entry when I click on it we land exactly on the currents state of the suffer documentation and The same is For our own documentation on the bridle side This is a complete different document and the suffer documentation is maintained by suffer and the community and our own bridle documentation is maintained by us and What we have also do is to introduce a new perspective of documentation For example, the take a k-config Zumba library or the device tree bind Things that is more a reference for programmer and so All these components are split it up from the original suffer documentation so that you can search again as you know it from the suffer documentation, but now Includes all the symbols we made in our own environment in the bridle environment and This is exactly the case for the device bindings Furthermore, we see the API's are a little bit hidden in the original documentation and so we split it Also the API's we have our own API's started and We can also see the API provided by suffer and so that all is Splitted and provided in different perspectives for a given version and on the end you have the same environment for all historical versions and when we go really really far away back You see the documentation is complete different and also The doc sets are slightly different so How it works a quick overview We're in bridle have our own documentation folder. It's the same as suffer And then we provide our own CMAC magic to create different build environments And that is a point where we split up the different perspectives and bridle separate k-config in device tree environments And then we protesting in the same manner as suffer with things and oxygen over the content and on the end We result in different sets of documents That's Happen for all version we maintain Is it a release that? then we have a release tech and it works on this pattern and Heavy a branch then it's the same situation and we have an head on a different released branch and also on the latest greatest Documentation that reflects the main branches of suffer and bridle Let me show some artifacts only a few artifacts What it what is possible in a downstream environment? Really interesting is That you are able to extend your wrist command environment and also the CMAC extension Yes, we know suffer provides you with some nice tools and on the CMAC level and also on the rest level and With the current state You have no problem to create new boards new subsystem and so on application development and so on but what is not really? Knowing about the other tools that you can also extend the best command environment and the CMAC and let me start with the CMAC for understanding What we provide with bridle is a little bit more extension in the boilerplate sequence so Why we do this? Yes, we try to create a blueprint for medical products and so and this environment You will need some fix two versions because the most of Medical developers have to fix the versions because they have a validated tool Maybe they need not the suffer SDK or more a validated tool from Made by arm for example, and so We need some prepared setups what is required to build the bridle project and Also, we made some checks if this description is also valid found on your build environment and so the working behind this is really simple all application we're looking for suffer and server provides an CMAC config package for this and this entry is a default Sequence to set up the server boilerplate and before this is happen Suffer itself looking in all sub modules in all server modules If there are any kind of a suffer build configuration environment When this happen for example here in our bridle we Inject some new CMAC modules that process our requirements our version checkups guards for the toolchain and then suffer goes on with the Rest of the boilerplate set up and so you can be safe set your application has The right environment to build for a medical device There are some more features Please have a look on the online presentation. There are some more slides what bridle Will provide in the future for this or what currently is really working Behind this magic. We have also some protection to create our document sets On the end we have start to create our own rest command because one of the CMAC integration and bridle is that CMAC tries to provide an its own CMAC package So that you can later create a freestyle or freestanding application looking not looking for suffer because looking for bridle and Then bridle do all the job to set up the right boilerplate To create your application against a workspace that is bridle and not suffer alone so on the end yes We create for for preparation on this our own command so that rest can be used as a meta tool to export the bridle CMAC package in your home space and The goal behind this is when we have a quick look on the implementation That here This is a common case when you start with your own command that you need an constructor and command line parser and a runner and in the implementation of the runner you stumbled over this Line and see oh now I need a runner that called CMAC and exactly that is always implemented in the suffer environment and What we do here that is a good example for you maybe We try to avoid reinvention of a real what is rolling since years and so what we need on this point is to Extend our search path on python Though that we can import the original functional implementation of the run CMAC method and The trick behind this is a new feature in west maybe since last summer That we can add besides your path Information where suffer live also our own key value pairs for a hint for our own trampoline code that we can Combine a search path on the end that under suffer script West commands will live the original implementation of our of the suffer functionality to run CMAC so The solution on the end is to go over two different decorators on the python environment The one decorator Looking for the right this path Content extends this path that will happen on the only ones on this line here and The second decorator Will be Will be added or fixed the runtime environment for the for the python scripts That you have and global symbol towards the to the original method in the suffer environment and On the end your implementation looks similar as to the beginning, but now you only need to add one decorator and This what we see here is Exactly the same Of the rest command extension in suffer when suffer made a suffer export Now we have a bridal export and the only extension is this declaration magic so that we can reuse as original implementation to call a CMAC a command Behind the scene as suffer do Yeah Yes, only a quick overview because We know that there is an example application in the suffer project how you can start with the downstream application and development That's okay for beginning and when you only will play with suffer with a freestanding Environment or your own downstream development you can do this on the end bridal have tried to extend the functionality of such kind of example To a more professional and product productive downstream project. So the red label things is more or less the The features you will get when you study the bridal source code and Yes For you is an offer for you. You can also start quickly with With bridal itself. We have a getting started page You can see how should I set up install the source code and made a quick hello world That's in common case similar as if you would like start with suffer itself, you need Your toolchain you need your host tools You need a python virtual environment get your code Through the vest manifest file and You made some extensions in your CMAKE environment with the experts and On the end you can start with a quick hello world and But what will be new when you do this you see that suffer will notify it's there and bridal and bridal also say hey, I'm happy I found exactly the version of the SDK you will need That is a new feature that only bridal provides Reflected on your ideas of our product development. That is exactly this was an medical developer would need on the end a short summary Where you can identify was suffer downstream project is It has your project has an vest manifest exactly this manifest That defined your software structure Your project will be a suffer module so that you can Edit your exit or entry points for the several tool framework At least you will create your own kconfig and CMAKE environment and maybe a little bit more frenzy as you need and If required you added your own rest commands in a similar case as we have done with the example with the export So that's why we say bridal is a little bit more as a example as a standard example But this is also the reason why we release it in public as soon as possible so that other people have a big picture what is on the end possible with the suffer's tool landscape so that you can Come in sooner in your own professional workflow a short highlights. I will notify you We have some of our own boards some boards of this are not yet supported by suffer So that was a good place to start with such kind of boards For example the lotus from Siege studio That is for us exactly the plan to qualify new ideas and Later in this year we start to integrate it in the suffer upstream and also we have start with some tests of new strategies to come in with some architectural ideas to play with the with the tool landscape from Saffa that is behind the Siege studio proof interconnected shields Yeah, we have our own application tests apis and so on and Yeah, we have also a Much full list of things to do in sorted in When you see some interesting points here come to us talk with us You can arrive us over github or discord Yeah, I have to say thank you for your attention and And What more take over to you there any question. Yeah, thank you