This page provides a suggested workflow for easily creating the basis of your Adaptive Application using the 
Application Design Center. The purpose of the Application Design Center is to assist you in quickly setting up an Adaptive Application from scratch to a, more or less, ready-to-use C++ project where you can begin inserting your application code.
The Application Design Center also offers functionality to quickly model test stubs to be used to test your application at appropriate points in the creation process, which are briefly discussed in this workflow. This gives you the means to easily confirm that the components of your Adaptive Application work without the need for an extensive or specialized testing environment.
While this workflow describes a process where you build your application from scratch, it is certainly possible to use many of the sub-editors of the Application Design Center individually.
Keep in mind that as the Application Design Center offers a streamlined process, it has somewhat scaled-down functionality at certain points of the process. Therefore, we recommend doing more detailed additions to the model generated in this process outside of the Application Design Center (see Step 9).
Be aware that with new MICROSAR Adaptive BSW Package releases there may arise a need to edit certain Model Extensions. Go to the Release Notes to find out which MICROSAR release the Application Design Center has been tested with, and whether you need to refer to your current MICROSAR Adaptive BSW Package version's release notes and technical reference document for eventual configuration.
General Overview
The first three sub-editors of the Application Design Center concern the definition of application design elements that are needed to generate the deployment parts of the model. Starting from the top, these sub-editors are as follows:
Data Types,
Service Interfaces, and 
Executables.
The logic behind this particular order is to represent a structural hierarchy: Data Types are used by Service Interfaces, which (together with the business logic) make up an Executable. In this workflow, however, we would recommend starting with the more complex element (the Executable) and working your way down to the detailed elements (Service Interfaces and Data Types) in an iterative fashion. By doing this, you can first focus on the purpose and general structure of your Adaptive Application, and the aggregated elements needed to achieve this will become clear to you along the way.
Step 1: Create and Configure your Executables
Start with creating the Executables and their accompanying Software Components needed for your Adaptive Application in the Executables sub-editor.
The Executable represents the binary that will be executed when deployed as a process. Defining the Executables then represents the processes that will be running when deploying the application to a target (development machine or a test target).
For each Executable you can configure which MICROSAR Adaptive ara::com and ara::core API versions will be used. The MICROSAR Adaptive Parameter BswVersionedApi can be set for each Executable in the Executables sub-editor. If not set, the default value for these variables are r18_03 for ara::com and r19_03 for ara::core.
Step 2, Step 3: Define Service Interfaces and the Used Data Types
After having the Executables defined, it is time to decide how they should communicate with each other (internal communication) and how the application shall communicate with surrounding applications (external communication). Using the Service Interfaces and Data Types sub-editors, the Service Interfaces used for definition of this communication can be designed and then used when defining the ports for you Executables. The ports are defined by going back to the Executables sub-editor, selecting the 
Adaptive Application SW Component Type in the tree view and then going to the appropriate tab in the Ports area.
Now that the basic design elements are configured, the next steps cover the deployment model: 
Application Design Center.
Step 4: Define Your Application
Navigate to the Application Design Center sub-editor, where we start drawing up the frame of your Adaptive Application by selecting the Executables intended to be part of your application.
Step 5: Set up Internal Port Connections
While still in the Application Design Center sub-editor, the tab Port Connections can be used to set up the internal connections between the Executables in the application. This will define how the flow of information will look in your application. This is applicable if the application consists of more than one Executable.
To create a Port Connection, select the Service Consumers to each of their matching (same Service Interface) Service Provider and click the 
Create Connection icon between the tables. While this is only a setup of internal communication, it is also important to realize that a Port can be used for both external and internal communication.
Step 6: Configure Your Deployment Settings
Still, in the Application Design Center sub-editor, we start by configuring where our deployment elements end up when generating. This is done by setting the root ARPackage for the model elements, as well as the ARXML file to which the deployment elements will be saved.
Next, depending on the communication needs of your Adaptive Application's ports, select whether the deployment for SOME/IP (external/internal) or IPC (internal) shall be generated by activating the corresponding checkboxes. For simplicity, it is only possible to set either one or the other. This means that if your Adaptive Application needs both deployments, this can be configured on a more detailed level for each port outside of the Application Design Center after you have built your deployment model (see step 9).
Further settings can be configured in the following tabs of the Application Design Center sub-editor:
On the Machine Network Properties tab, the machine's network name, as well as the multicast and unicast addresses, can be set.
On the Machine Properties tab, we find various start values for identifiers used by the communication services.
The Logging Properties tab allows us to define the level of feedback we want our Executables to report through the log channels. We can also set the logging output to a console and/or a specified file. For simplicity, these settings are applied to all of your application's Executables. For more detailed, individual logging configurations you may use the Machine Editor after you have built your deployment model (see step 9).
Step 7: Configure a Test Stub
If you need to test your application, you'll need a test stub. A stub can be described as an interactive counterpart to your application, which has ports configured to connect to and meet the needs of each of your application's ports. The stub can then be used to simulate the providing or consuming of the ports your application makes use of, which enables you to test the application's input and output without needing an extensive testing environment.
In the event of errors, having to troubleshoot your entire application can be difficult, which can be minimized with good testing practices. As a good testing practice, we would recommend making sure that you iteratively test each of your application's components in isolation as they are created, then moving on to testing several components working together, and finally testing the Adaptive Application as a whole. By doing this, you will be able to easily identify any eventual errors early in the process. These test scenarios can be accomplished using the test stub. It all depends on which application ports are activated when configuring the stub.
Navigate to the Stub Configuration tab of the Application Design Center sub-editor. Here you'll see each of the Executable you have defined in the Included Executables tab as belonging to your application, along with their Ports.
To create a test stub for your application, simply include the Ports you wish to generate a counterpart to. When building your model, an Executable called TstStubForAdcApplication and all its deployment elements will be included. In the code for this Executable, you can create whatever tests you feel appropriate. Usually, the code of a stub tests the services of your component's ports, making sure that each input and output is as expected.
Step 8: Build Your Model
Click [Build Model] to generate your model. This will create your model's elements in neatly ordered ARPackages under the root ARPackage we defined in step 6, and save it to the defined ARXML file.
Step 9: If Needed, Add Additional Model Elements Outside of the Application Design Center
As the focus of the Application Design Center is to offer a streamlined process, it has scaled down functionality compared to the rest of the DaVinci Developer Adaptive tools. Therefore, it is recommended at this stage to consider whether a more detailed configuration of your model is needed, such as mixed IPC and SOME/IP deployments for your ports.
Step 10: Generate Source and Configuration Files From Your Model
Using the MICROSAR Adaptive generators, you can validate the built model and generate your source and configuration files. This is done using the Validation and Generation toolbar. The generated result will then be used in the next steps.
Step 11: Define the C++ Project Location and Basic Dependency Paths
Now that we have a complete model including the necessary deployment elements and the generated source and configuration files, we can use the 
Application Design Center sub-editor to build a, more or less, ready-to-use C++ project for it.
Among the main principles behind the founding of the AUTOSAR standard, we find words like modularity, reusability, and configurability. To carry these principles with us throughout the process of using AUTOSAR Adaptive / MICROSAR Adaptive, the Application Design Center sub-editor will provide you with the basis of a C++ project for your Adaptive Application in a specific structure which promotes the reusability of application code.
A generic tree structure of a C++ project generated in the Application Design Center sub-editor would look something like this:
IntegrationProject[1..1] 
Etc Someipd Someipd-posix-gen.json Someipd-posix.json CMakeLists.txt LocalPaths.cmake
ApplicationProject[1..*] Etc Include Src Executable[1..*] CMakeLists.txt Main.cpp CMakeLists.txt
As you can see, in the root directory of your application you'll have one separate Integration Project and as many application projects you want to include. The connection between these is based on the CMake build infrastructure, the structure of which will be briefly discussed here.
In the Integration Project, we find two noteworthy files: the LocalPaths.cmake and the CMakeLists.txt. The LocalPaths.cmake contains path references to four critical build components: the MICROSAR Adaptive platform SDK, the MICROSAR Adaptive Runtime, the application's source and configuration files, and the toolchain definition file.
The CMakeLists.txt file can be viewed as the top-level file for the entire CMake structure of your C++ project, as it adds each application project as a sub-directory. Each application project, in turn, has its own CMake structure with a top-level CMakeLists.txt acting as an entry point to each of its Executables, by adding them as sub-directories. Finally, each Executable has its own CMakeLists.txt which links to the MICROSAR Adaptive support libraries necessary for its function and builds the resulting target.
This separation of integration and application project is meant to promote the reusability of your applications across different system configurations. If properly used, this can mean using your applications on, say, a different model of a vehicle could be as simple as switching out your Integration Project. All of this, and more, is possible to easily generate in the Application Design Center sub-editor.
Navigate to the Application Design Center sub-editor, where we can begin at the top of the screen with the C++ Project Root setting, where you define the root directory where you would like your C++ project to be built. Beneath this setting, fill in the three dependency paths necessary for your application to run correctly. These paths lead to the critical build components that go into your Integration Project's LocalPaths.cmake, which are as follows:
MSRA Generation Result Root
Where your source and configuration files end up when you use the MICROSAR Adaptive generators on your model, the src-gen folder.
Platform SDK Root
The Software Development Kit created by building the MICROSAR Adaptive Platform.
Platform Runtime Root
The Runtime parts of the MICROSAR Adaptive Platform.
The Basic Software Package for MICROSAR Adaptive includes the TACO build system, which is based on CMake. This allows you to build the Basic Software Package and install it using CMake commands (See User Manual of MICROSAR Adaptive for more information). The purpose of this is to build the BSW once and use the result when building individual applications.
The Platform SDK is the folder where the CMake component "AMSR_Development" is installed. It contains the libraries and header files of the BSW.
The Platform Runtime is the folder where the CMake component "AMSR_Runtime" is installed. It contains the Platform executable binaries and their runtime configuration.
If no component is defined with the CMake install command, then the install folder will contain everything. Thus, the Platform SDK and Runtime will have the same root folder. Please be aware that MICROSAR currently supports only the case where the MSRA Platform SDK and Platform Runtime are in the same folder.
Step 12: Setup the C++ Project Structure
Now it's time to define which Integration Project, Application Projects, and accompanying Executables are part of your C++ project in the Application Design Center sub-editor. What you need to configure here is one Integration Project and one or more Application Projects, which in turn has one or more Executables. This is done in the tab C++ Project Setup, where, at this stage, you can see the name of your Adaptive Application, which was configured earlier in the Application Design Center sub-editor, as the root node of the tree.
If you have defined which Executables are part of your application in the Application Design Center sub-editor, you can simply click the 
Create from Model Builder icon to import that configuration. This will create one Integration Project with one Application Project, inside of which all configured Executables will be placed. The name of your projects can be edited by selecting the project and clicking the respective cell again.
If you have not defined the Application Executables in the Application Design Center sub-editor, or if you wish to split up your Executables in several Application Projects, you can use the 
Add icon to manually set up your C++ project. The Add icon of this table is context sensitive, which means different parts will be added depending on what is being selected in the table when clicking. Start by selecting the name of your application and click Add to add an Integration Project to the list. Now select the Integration Project and add as many Application Projects as you need. To add your Executables, select the appropriate Application Project and click Add to bring up the Select Executable dialog where you can select which Executables to add.
As test stubs aren't supposed to be a part of your final application, in this workflow they are not included in the Executables list of the Application Design Center sub-editor. If you have created test stubs, you will need to add them manually at this stage by clicking Add and selecting your test stub Executable.
While the Execution Manager and SOME/IP Daemon are considered to be part of the basic platform, they still need to be part of your model as Executables. Specify which Executables represent your Execution Manager and SOME/IP Daemon in the Basic Platform Components area so the CMake structure has access to their given names.
If you wish, you can also edit the names of the Source, Include, and Config folders which will be created, in the Directory Structure area of the C++ Project Setup tab. These name changes will also be reflected in the created CMake files.
Step 13: Setup the C++ Project Properties
Now it's time to set up the various CMake variables that will enable your application to run properly in the target environment. While still in the C++ Project Setup tab of the Application Design Center sub-editor, when selecting an Executable, you'll notice that the Executable properties area becomes available to you. In this area, you can define what MICROSAR Adaptive components each Executable makes use of, either by activating the check boxes of the commonly available MICROSAR Adaptive components, or adding whichever component names your application need to link to by clicking Add Component on the left side of the Additional components for linking table.
Moving on to the tab C++ Project Properties, there are several CMake variables that can be configured. First, fill in the Machine Name with the ShortName of the machine in your model. If you have set this value in the Model Builder sub-edditor, you can simply use the Copy from Model Builder button next to the field. Second, fill in the CMake Tool Chain File Path, where architecture, compiler, and various options are defined. These can usually be found in your BSW Package, in the CMake | Toolchain folder, where you must select the same version, you defined when building the BSW SDK. Third, fill in the Deploy Package Root (Install Prefix), defining the location of the deployment package.
The other variables on this tab (Project Description,Company Name ,CMake Minimum Required Version, C Standard, and C++ Standard) are mainly to help you neatly document your C++ project, and they will be added to the Integration Project's top-level CMakeLists.txt. Except for your project description, these are pre-filled with values we expect you are using for your C++ project, though can be changed if need be.
Step 14: Set Build Template Configuration (Optional)
If you want to further customize the output of the Project Builder, see the Build Template Configuration section.
Step 15: Build your C++ Project
At the top of the Application Design Center sub-editor you'll find the [Build C++ Project] button, which you can click to generate your C++ project.
Step 16: Replace the Hello World Example With Your Business Logic and Install
In your newly created C++ project, you'll find a Hello World example in each of your Executables' Main.cpp files. Replace this with your business logic. After running the install commands, there will be a deploy package in the earlier configured Deploy Package Root, containing all configuration files and binaries, from which you can run your application.