[Withdrawn] SDL 0331 - Add new SDL System Structure using Mediation Application for middle/low-end class model of Powered Two Wheeler and low-cost vehicle models
theresalech opened this issue · 22 comments
Hello SDL community,
The review of "SDL 0331 - Add new SDL System Structure using Mediation Application for middle/low-end class model of Powered Two Wheeler and low-cost vehicle models" begins now and runs through July 27, 2021. The original review of this proposal took place April 28 - June 1, 2021. The proposal is available here:
Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:
- Is the problem being addressed significant enough to warrant a change to SDL?
- Does this proposal fit well with the feel and direction of SDL?
- If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Please state explicitly whether you believe that the proposal should be accepted into SDL.
More information about the SDL evolution process is available at
https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md
Thank you,
Theresa Lech
Program Manager - Livio
theresa@livio.io
Please find collective feedback from the Project Maintainer below, and let us know your thoughts. Thank you!
1.
As already discussed on the previous proposal regarding this topic and “high level” proposals,
The purpose of the evolution process is not for agreeing to high level concepts or policies. Therefore without the additional technical details attached to this idea, it is not possible to accurately judge or provide a vote of acceptance on such a proposal. While the SDLC can see benefit in pursuing SDL for Motorcycles, it is not possible to give an open ended approval on such a feature until all the information is provided and properly reviewed.
The author has provided a little more detail into what they would like to happen, but the proposal lacks many details on how that would be accomplished. Since this has already been discussed I would have expected the author to take that into consideration before providing an additional proposal that lacks critical details.This would include questions that were asked on the previous proposal like what are the hardware requirements, what programming language would be considered, etc. Because of this reason alone the proposal should likely be taken out of review and the author revise to contain specific details on how this proposal could be implemented.
2.
To SDL Core
There are no changes from current SDL Core.
This is false. There is no possible way to simply take SDL Core as it is today and compile it for Android and iOS; there would be a significant amount of refactoring done to support dependencies that do not exist on those platforms. The author should know this. Providing such a statement like this in the proposal is extremely disingenuous and invites even heavier scrutiny into what else is included in the proposal. The author does not even provide a hint as to how they expect to compile Core for iOS.
3.
How does the author plan to perform IPC (inter process communication) on both the Android and iOS platform to allow apps to communicate with this mediation app? While IPC is possible on Android with caveats, on iOS there is no effective way to achieve this. For example:
-
- The iOS SDL apps would need to run in the background to communicate with the “SDL mediation” app, but this is impossible as iOS has no background capabilities for something like this.
-
- The iOS SDL apps would need to communicate with the “SDL mediation” app, but this is impossible on iOS, which has no cross-app communication.
4.
Is this mediation app another app that the SDLC would maintain? If not, how do we ensure that this new system works as it should and we don’t break things with new releases?
5.
Why can’t the ECU use the mobile API and skip adding Core altogether? There is nothing stating you can’t create your own version of Core on the IVI or ECU and use the RPC spec as the main communication between apps and your hardware.
6.
How does the mediation app connect to the ECU/IVI’s HMI? If it’s bluetooth or USB then that’s another modification SDL Core is going to require.
7.
It seems the author believes that they can create support for the low-end model hardware that can process HMI messages and follow the guidelines as written today. I don’t see how this could be the case. I believe the author would need to rework guidelines for HMI integrations to fit the potential solution provided in the proposal.
8.
An “app store” is mentioned; what is this in reference to? Is it a new aspect to the project that needs to be included? Why is it necessary in this proposal or more simply, how is it used?
9.
“Add function to” is used extensively and is seen essentially as hand-waving and is unacceptable for an evolution proposal.
10.
Internally the Project Maintainer has discussed adding Android support to Core and looked at how best to achieve that while keeping the technical debt low. Based on our initial investigation, it will be a challenge. This proposal seems to portray that it is not difficult. If the author has specific knowledge on why it is believed to be the case, it would be really good to include that information in the proposal.
11.
There's no mention in this proposal of excluding features that won't work over the hmi_api, such as video streaming.
12.
The current SDL system is mainly for four-wheeled vehicles and requires a high-performance/high-resolution system (the binary size is 177MB when built with x86_64.).
This statement is referring to the binary size of SDL Core built in debug mode with no compiler optimizations. Building SDL Core with Release mode and max compiler optimizations leads to a binary size of 16MB. The proposal should be updated to show the correct optimized build size of the binary.
13.
The proposal does not explain any of the hardware requirements needed for the system this solution is being built for. Please include the hardware requirements.
14.
In figure 2, the chart mentions the "Communication Protocol"; is this going to be a new c++ application? How will this work?
15.
The new SDL system will use Bluetooth Low Energy (BLE) for communication, so there will be no impact on the existing code.
None of the current projects use BLE, therefore there would absolutely need to be modification to any project that would use that. All of the current transports send messages in a synchronous, in-order method, whereas BLE would potentially allow for messages to be read and sent out of order; therefore there must be details included on how the existing messages would work "sent" over BLE.
16.
It will use the current SDL Core.
Is this forever? Will it never be updated? We've already asked if the mediation app is per-OEM or managed by the SDLC. If the former, are OEMs not allowed to update to a newer Core version? If the latter, will the SDLC never update the app?
17.
There is not any management of the SDL HMI, only managing the integration guidelines.
Could you please explain this? Do you mean that sdl_hmi will work without modifications in the mediation app? What integration guidelines need updating and why do they need updating if sdl_hmi has no changes?
18.
In the case of a HU with low performance ECU, there is no OS and the programming language is different. Therefore, generalization is not possible.
Generalization of what? As in the SDLC cannot make the head unit component for general use? Why not use C?
19.
The App Library will be shared by adding a function to determine if it is a low performance ECU system. From the above, the management and maintenance of the Mediation App would be newly generated.
How will it determine if it's a low-performance ECU system if there's no external connection between the app (other than the mediation app) and the head unit?
20.
There will be no impact on existing code as the new SDL system will still use SHAID as before.
We believe that the new SDL system as described wouldn't use SHAID at all. Could you explain how it would use SHAID "as before?"
21.
There will be no impact on existing [Policy Server] code as it is created for each system and OEM.
This is not true. The SDLC develops the example policy server which each OEM uses. How will this new system use the policy server and how would the example policy server need to change?
22.
For both the Mobile and HMI APIs, there will be no additional RPCs, but parameters will be added. As an example, adding a parameter to VehicleType to indicate a low performance ECU and to DisplayType to indicate the PTW display type is considered
Please list the explicit changes to the APIs for consideration.
Per the author's request, the Steering Committee voted to keep this proposal in review, to allow the author more time to respond to the comments on the review issue. It was advised that if the author is unable to respond before our next meeting, the proposal will enter a “deferred” state, per the SDL Evolution Process.
@theresalech -san,
Thank you for your comments, and sorry for our late response.
Since there were a lot of comments, we could not reply soon.
Anyway, we left some comments which we can respond at this time.
If it is possible, could you please confirm them.
Thank you.
We have already mentioned in this proposal, we assume that SDL Core can be implemented to the Mediation App as is by the implementation of NDK. Have you ever considered the NDK?
However, we are under consideration about iOS. If you have any solution, could you please provide us. Thank you.
i. We have a question. In the iOS SDL system, does it exist any HMI status such as BACKGROUND and LIMITED?
ii. We assume that the communication method between SDL app and Mediation app will use the socket communication protocol. In this matter, we plan to issue it after to be accepted this proposal.
We assume that Mediation app will be maintained and managed by SDLC.
Since the ECU does not have enough memory capacity to mount the improved SDL Core, only display RPC processing can be implemented.
We plan to communicate the code, which changed from RPCs according to the conversion table, to the ECU via BLE. In this matter, we plan to issue it after to be accepted this proposal.
We think the modification of HMI guideline is as the minimum solution. Also, we think the best solution is the modification of HMI integrated guideline. It needs to consider whether to remark the HMI integrated guideline.
"App store" refers to the site where you can downloaded the SDL apps.
It may not be necessary for this proposal as it is an additional feature of Mediation App. It is possible to delete it, but if it is in the Mediation App, only the SDL App can be displayed, so I think that it is a necessary function from the aspect of usability.
Since we would like to modify the words, could you please provide us what kind of the words are acceptable for you.
Currently, we are considering to mount SDL Core to Java by using NDK. After consideration, we will include something information in this proposal.
We are very sorry but it was lacked the description about this matter in this proposal. We will add the description that the function which does not work on hmi_api, such as video streaming, is out of scope in this proposal.
We will change the binary size from 177MB to 16MB.
The hardware requirement for this system is to mount the BLE connection.
By the way, if you have the hardware requirement for the current system, please provide us for the reference. Because we could not find out the hardware requirements of current system.
We assume the communication protocol is implemented the Mediation App. Therefore, if Android, it implements by Java. If iOS, it implements by Objective-C or Swift.
We assume it is necessary to implement for the BLE. However, it does not modify the existing communication protocol, it adds the new communication protocol. Therefore, it does not impact on existing code. If there is an impact only to add the BLE code, we will modify the description. If you mentioned about the system identification function and the function to switch the communication destination and method, we will add the description above.
The Mediation app will mount the latest SDL Core. Also, the Mediation app is created as a system, it has for Android and for iOS, is not created for each OEM. Therefore, when updating SDL Core, Mediation app also needs to be updated, but it will not support new features.
The HU which is used in this system, Ex. Meter Unit etc., almost does not mount OS, it uses the programing language according to the ECU. It can not be unified. Therefore, the HU developers need the documentation how to create the SDL HMI and communication protocol. If it does not need to describe, we will remove it.
We think the word unification is better than generalization. Anyway, since the programing languages on HU can not unify, we will provide the HMI guideline for HU developers.
We are under consideration.
However, we know that current SDL system does not have the BLE connection.
A new (low-performance) SDL system has only BLE connection.
We think the system can get this information by using BluetoothDevice::getType() method.
Thank you for your advice.
Regarding to SHAID, since this system will use SHAID as it is, we assume there are no changes.
If this system does not need to use SHAID, we will remove it.
Currently, we assume this system does not have any contents to add to policy table. This system will put the contents in policy table and use it as same as current system. Therefore, it is necessary to create policy server for each OEM, but policy server does not need to change themselves.
We assume that parameter of EcuPower will be added in the struct of VehicleType as below.
HMI API:
<struct name="VehicleType">
<param name="make" type="String" maxlength="500" mandatory="false">
<description>Make of the vehicle</description>
<description>e.g. Ford</description>
</param>
<param name="model" type="String" maxlength="500" mandatory="false">
<description>Model of the vehicle</description>
<description>e.g. Fiesta</description>
</param>
<param name="modelYear" type="String" maxlength="500" mandatory="false">
<description>Model Year of the vehicle</description>
<description>e.g. 2013</description>
</param>
<param name="trim" type="String" maxlength="500" mandatory="false">
<description>Trim of the vehicle</description>
<description>e.g. SE</description>
</param>
+ <param name="ecupower" type="EcuPower" mandatory="false">
+ <description>ECU Power for PTW system</description>
+ </param>
</struct>
</struct>
+ <enum name="EcuPower" since="6.0">
+ <description>System identification value for PTW</description>
+ <element name="HIGH" />
+ <element name="MIDDLE" />
+ <element name="LOW" />
+ </enum>The other hand, we assume that parameter of Displayable will be added in the struct of DisplayCapabilities as below.
HMI API:
<struct name="DisplayCapabilities">
<description>Contains information about the display capabilities.</description>
<param name="displayType" type="Common.DisplayType" mandatory="true">
<description>The type of the display. See DisplayType</description>
</param>
<param name="displayName" type="String" mandatory="false">
<description>The name of the display the app is connected to.</description>
</param>
<param name="textFields" type="Common.TextField" minsize="0" maxsize="100" array="true" mandatory="true">
<description>A set of all fields for text displaying supported by HU. See TextFieldName.</description>
<description>If there are no textfields supported, the empty array must be returned</description>
</param>
<param name="imageFields" type="Common.ImageField" minsize="1" maxsize="100" array="true" mandatory="false">
<description>A set of all fields that support images. See ImageField</description>
</param>
<param name="mediaClockFormats" type="Common.MediaClockFormat" minsize="0" maxsize="100" array="true" mandatory="true">
<description>A set of all supported formats of the media clock. See MediaClockFormat</description>
</param>
<param name="imageCapabilities" type="Common.ImageType" array="true" minsize="0" maxsize="2" mandatory="false">
</param>
<param name="graphicSupported" type="Boolean" mandatory="true">
<description>The display's persistent screen supports referencing a static or dynamic image.</description>
</param>
<param name="templatesAvailable" type="String" minsize="0" maxsize="100" maxlength="100" array="true" mandatory="true">
<description>A set of all predefined persistent display templates available on headunit. To be referenced in SetDisplayLayout.</description>
</param>
<param name="screenParams" type="Common.ScreenParams" mandatory="false">
<description>A set of all parameters related to a prescribed screen area (e.g. for video / touch input).</description>
</param>
<param name="numCustomPresetsAvailable" type="Integer" minvalue="1" maxvalue="100" mandatory="false">
<description>The number of on-screen custom presets available (if any); otherwise omitted.</description>
</param>
+ <param name="displayable" type="Boolean" mandatory="false">
+ <description>A value showed whather HU has somthing to display or not.</description>
+ </param>
</struct>@Akihiro-Miyazaki - Please find the collective feedback from the Project Maintainer below, and let us know your thoughts. Thank you!
1. Please review and provide your response to this question.
2. Yes, we know what the NDK is. Your response did not answer the question. Please provide how you believe that Core will not require any modification and simply compile for both mobile platforms. While the NDK allows C++ code to compile alongside Java, it is not a powerful enough tool to migrate dependencies that do not exist on the platform the code is being compiled for. There are also multiple architectures for Android devices which must be considered. For iOS, it is the responsibility of the author to perform the due diligence that the solution they are proposing is possible. If this information is not provided there is no reason to continue reviewing as the implementation is not feasible.
3. The author did not provide a meaningful answer to this question. Again, it is the responsibility of the author to perform the due diligence that the solution they are proposing is possible. If this information is not provided there is no reason to continue reviewing as the implementation is not feasible.
4. How often should this app be updated? Is this app pushed to the app stores? If so, what regions and stores? Is the SDLC going to authoring their own production apps? If so, does this violate any anti-trust laws that the Board of Directors needs to be aware of?
5. The author did not provide a meaningful answer to this question. Why can't the ECU handle RPCs using the RPC spec and not having to build Core onto the mobile device? You do not have to implement the full Core onto the ECU and thus could simply process UI RPCs with a modified spec/guidelines.
6. What is this conversion table? It is not present in the proposal. This would appear to be an extremely important part of this solution and should be included in this proposal, not a different proposal. This proposal will not be accepted until the implementation is feasible, and these key details are crucial for that.
7. This would appear to be an extremely important part of this solution and should be included in this proposal, not a different proposal. This proposal will not be accepted until the implementation is feasible, and these key details are crucial for that.
8. So the mediation app includes Core AND an app store? Why can't the same mobile app stores be used? Are you implying that the mediation app would also be able to run other types of apps like Javascript apps? That is nowhere in the proposal and adds another complexity to this proposal that lacks any implementable solution provided.
9. This is not about modifying words, it is about providing actual code snippets and examples of what the solution would potentially be. Using language like "add function" is near meaningless in terms of an evolution proposal as it is not understood what the author intends. The action item here would be for the author to provide snippets and examples of exactly what they intend.
10. We will await your additional information on how Core can be compiled through the NDK including potential missing dependencies.
11. Out of scope or never allowed? The way this has been designed seems that it will never work, and is therefore forever excluded. We are just looking for this to be acknowledged and noted in the proposal.
12. 👍
13. What are the hardware specs for the metered head unit this proposal is being designed for?
14. Figure 2 shows 4 components on the metered head unit. What are the Communication Protocol and SDL HMI components in the metered head unit diagram? How much ram/disk space will be allotted for SDL-related components on the metered head unit?
15. Adding a BLE transport is modifying the code base, this is an absolute fact. Just because you create a new transport doesn't mean the library will know how to change sending these messages or how Core would know how to send these messages. You must address how this will affect the message flow. It goes back to the lack of information regarding this new "communication protocol". The author desperately needs to include more details on this solution so each of the pieces can be fit together. Right now, it's impossible to give meaningful reviews on bits and pieces of an ad hoc solution.
16. Therefore, when updating SDL Core, the Mediation app also needs to be updated, but it will not support new features.
This is completely contradictory. How much time and effort do you anticipate this placing upon the maintainers to support this new project? It appears to be significant. What if new dependencies are added to Core that need to be ported to iOS and Android? This is placing a large burden upon the mobile teams of the maintainer.
Additionally, SDL Core and HMI versions are closely aligned. They are not versioned like the mobile API. Therefore dropping in a new Core version to the mediation app has a high likelihood of breaking the connected low-cost ECUs.
It is the responsibility of the author to perform due diligence about the added work a new platform brings to the project. This would be a significant recurring investment that the SDLC must make or the feature will begin to fail. If this information is not provided there is no reason to continue reviewing as the implementation is not feasible.
17. We believe you need to add example information about what will be added to the integration guidelines. This seems to be a significant and missing part of this proposal.
18. We will drop this point.
19. We will await your full response.
20. Based on your answer, we believe this section can be entirely removed.
21. Please add this to the proposal for further consideration.
22. What defines a vehicle's EcuPower as high, middle, or low? Additionally, We don't believe that the description for displayable is enough to understand what this parameter indicates. Finally, there are no MOBILE_API changes listed. Are these assumed to be the same as the HMI_API changes?
The Steering Committee voted to keep this proposal in review to allow for the conversation to continue on the open items in this comment.
@jordynmackool -san,
Thank you for your comments and sorry for our late response.
Now, we are talking about the almost of your comments internally. We can not leave all our comments. Thus, we left some comments below.
The update frequency of the Mediation app is same as SDL Core's one.
We assume that this Mediation app is pushed to the app stores for free download. We think the madiation app is provide the user by free same as SDL app library, SDL Core, and SDL HMI. What kind of matter violates any anti-trust laws? Also, the regions depend on each OEM.
Since Mediation app will mounts SDL Core, we recognize SDL Core is existed on the mobile device. We assume that ECU will address the HMI API (only concern the display and operation). However, since RPC communication load will be increased to communicate current RPC as it is, we will reduce the communication load by convert to ID code.
The Mediation app includes the SDL Core but does not include the App stores. The Mediation app can only display the list of SDL app and select the SDL app which user wants to. After selected the SDL app, the Mediation app switches to App stores to download the SDL app.
Since this system will use the BLE communication, large amount of data such as the video streaming can not transport each other. Also, the almost of HU which must be used this system may not have something to display.
The ECU performance and memory capacities are important, but these are not limitation. Because the every system which have enough ECU performance and memory capacities can select this system. This system must communicate via BLE, therefore we think this is limitation.
The communication protocol means the component to address the BLE communication. We assume HU can communicate the HMI API to the mobile device via this communication protocol.
The change contents are below.
Addition of the process of BLE transport.
Addition of the process to get identification data to determine which transports does system select.
Addition of the process to determine which transports does system select by using the identification data above.
Addition (or Modification) of the process to switch the transport.
Since these changes above will be implement, therefore, there will be impact on these parts of existing code.
We will modify the comment above.
Could you please teach us if there are comments.
We think that the best reason to use Latest of SDL Core is to fix bugs.
As the reviewer commented, we assume that implementing Latest requires a minimum of support to get it working. We would like to not support new features other than the above as much as possible. This system is basically assumed to be operated with limited functions as a low-priced system.
Okay, we will remove this point from this proposal.
Okay, we will remove this point from this proposal.
Okay, we will add this information to this proposal.
For EcuPower, OEM judges comprehensively the performance of ECU, memory capacity, presence or absence of Display, etc.
The "low" condition is a HU that cannot be equipped with the current SDL System SDL Core and SDL HMI, and is capable of BLE communication without a Display.
The "medium" condition is that BLE communication is possible, Display is mounted, SDL Core and SDL HMI of the current SDL System cannot be implemented, or HU that wants to implement this SDL System.
The "high" condition is HU that does not apply to " low " and " medium ".
I think that the change to MOBILE_API is basically the same. However, it is assumed that there is a base structure on the MOBILE_API.
Hi @Akihiro-Miyazaki , thanks for your responses. We will wait for all items to be addressed by the Nexty team before responding, as to keep the discussion as clear as possible for SDLC members to follow.
The Steering Committee voted to keep this proposal in review, to allow the author additional time to discuss the open items with the Japanese sub-committee, and respond on the review issue. It was noted that the following items still require a response from the author: 1, 2, 3, 6, 7, 9, 10, 17, 19.
Since the discussions on the Japanese side have not been summarized, we want to keep in review.
This proposal has been deferred in accordance with this section of the SDL Evolution Process document. During the 2021-06-01 Steering Committee meeting, the proposal author was unable to confirm that they would respond to the comments before our next Steering Committee meeting (2021-06-08), as the next Japanese sub-committee meeting will not take place until 2021-06-10. Therefore, the proposal will remain deferred until the author has acknowledged (via email to sdlc@smartdevicelink.com) that they are able to respond to the open items within the comments on the review issue.
Hi @Akihiro-Miyazaki and @Koji-Futami , can you please email sdlc@smartdevicelink.com if you are able to respond to the open items here, so that we can bring this proposal back into review? If you are unable to respond to the open items at this time, we will need to close this proposal review issue for inactivity and will re-open once you're ready to take action, per this section of the SDL Evolution Process document.
Closing as inactive. The issue will remain in a deferred status and unlocked so the author can notify the Project Maintainer when it is ready to be revisited.
The author confirmed that they will be able to respond to the open items on the review issue before our next meeting on 2021-07-27. Therefore, this proposal can be reopened and brought back into review. The review runs through July 27, 2021.
@theresalech -san,
Thank you for reopening.
We will comment on the unanswered part, so please check it. As we talked about at the Steering Committee Meeting, we would like to separate proposals when it comes to functional design.
We have already answered 5,8,13,15,18,20,21,22, so please comment.
Move to the separate proposal
Move to the separate proposal
Move to the separate proposal
We think the questions about antitrust law are different from the technical issue. We believe that legal are managed by the SDLC. So would you please take this issue out of the scope of this Proposal?
Move to the separate proposal
Move to the separate proposal
Move to the separate proposal
Move to the separate proposal
Of the HMI APIs, Video-Streaming is Out of Scope because this system does not assume a large amount of data communication. TTS, VR, and RemoteContorol are not implemented, so they are never allowed in Meter head u
nit.
The capacity allocated to SDL components by low-cost Meter head unit varies depending on each OEM, but it is assumed to be about a few hundred KB.
Since the SDLCore used in the Mediation Application uses the latest version as it is, the Mediation Application needs to be updated along with the SDLCore version update.
Move to the separate proposal
Move to the separate proposal
@theresalech -san
Please support your team so that you can give us FB ASAP.
Please find collective feedback from the Project Maintainer below. Thank you!
Open Items
1.
We disagree that technical details for this feature should be provided in a separate proposal. As we originally stated on the first proposal for this feature (#1004), and have now reiterated in our comments on this proposal's review issue, in order for the Steering Committee to decide if a proposal should be accepted, we must be able to understand how the feature would be implemented. This requires technical details to determine both project impact and feasibility. Per the SDL Evolution proposal template, "The detail in this [Proposed solution] section should be sufficient for someone who is not one of the authors to be able to reasonably implement the feature and future smartdevicelink.com guides." This requirement is not met by this proposal as it currently stands. Hardware requirements, programming language, and other questions left on the previous proposal should be answered in this proposal in order for it to be considered for acceptance.
2.
Similarly to 1, we disagree that these technical details should be provided in a separate proposal, as they are essential for understanding the feasibility of implementing the proposed feature, and are required for meeting the criteria of the Proposed solution section in the proposal template. Please provide an answer to this item.
3.
Similarly to 1, we disagree that these technical details should be provided in a separate proposal, as they are essential for understanding the feasibility of implementing the proposed feature, and are required for meeting the criteria of the Proposed solution section in the proposal template. Please provide an answer to this item.
4.
While the SDLC does have legal counsel, it is not SDLC counsel's responsibility to advise on features being proposed by members. It is the responsibility of the member proposing the feature to understand legal implications and confirm that their proposal does not violate any laws, anti-trust or otherwise. Please see an example of a previous proposal which required members' legal input: #356 (comment). If the mediation app is provided as a sample application, and not production to be released by the SDLC into app stores, this would fall along the same lines as other SDLC projects, and therefore not violate anti-trust.
5.
It seems the author misunderstands my question. If the IVI system can handle the RPC spec messages from the library, then Core does not need to be implemented into the mobile devices at all. This would prevent a lot of overhead into this proposal. The IVI could have a smaller version of Core that handled the RPC messages and skipped creating HMI messages, but just directly sent content to the IVIs HMI through the RPC messages. So why is this not possible? Why does the IVI system HAVE to implement the HMI spec only and why does Core HAVE to be implemented into the mobile devices instead of just simply sending RPC spec messages as the mobile libraries do today?
6.
Similarly to 1, we disagree that these technical details should be provided in a separate proposal, as they are essential for understanding the feasibility of implementing the proposed feature, and are required for meeting the criteria of the Proposed solution section in the proposal template. Please provide an answer to this item.
7.
Similarly to 1, we disagree that these technical details should be provided in a separate proposal, as they are essential for understanding the feasibility of implementing the proposed feature, and are required for meeting the criteria of the Proposed solution section in the proposal template. Please provide an answer to this item.
8.
So the mediation app actually does include an "app store." The mediation app would need to have a list of SDL apps that the user could download. Even though the actual app is hosted on the native app stores, the mediation still has a requirement to be able to display additional apps that are not installed currently but are available to users, creating an app store front. Where are these requirements in the proposal? Where does it get the list of apps to display? Are those different per OEM or is this a list of ALL SDL apps?
9.
Similarly to 1, we disagree that these technical details should be provided in a separate proposal, as they are essential for understanding the feasibility of implementing the proposed feature, and are required for meeting the criteria of the Proposed solution section in the proposal template. Please provide an answer to this item.
10.
Similarly to 1, we disagree that these technical details should be provided in a separate proposal, as they are essential for understanding the feasibility of implementing the proposed feature, and are required for meeting the criteria of the Proposed solution section in the proposal template. Please provide an answer to this item.
11.
Please add "Video streaming will never work for these low-cost systems based on the design of this proposal" to the downsides section.
13.
This is answered by part of 14, below.
14.
The capacity allocated to SDL components by low-cost Meter head unit varies depending on each OEM, but it is assumed to be about a few hundred KB.
Ok thank you. We would request that the proposal at least includes this as an estimated requirement. This answers my question for 13.
We would still like to see some more details about the "communication protocol." Currently SDL Core communicates to the HMI via websockets and JSON rpc. Will SDL Core communicate to the "communication protocol" component in the same way? Modification to SDL Core would be required if the method of communication is not JSON messages over websockets.
15.
At a high level it seems like this is going towards the right path, however, as we've mentioned multiple times being specific is key. We will need specific details and code samples on how this would be done within each project it affects.
16.
You simply restated your earlier comment and did not respond to any of the most recent questions on this point. If you intend this point to stand without changes, this is my suggested language to add to the Potential downsides section:
This proposal adds the need for every release of Core to be ported to Android and iOS before release to be shipped in the mediation app. This will require exponentially more work and time on each release of Core, iOS and Android. Additionally, new features in Core that require dependencies may need to be rejected because of the need to port those dependencies to Android and iOS.
Additionally, please respond with how you intend to mitigate the mediation app breaking with low cost ECUs with every release of the mediation app due to HMI API spec breakage on every release.
17.
Similarly to 1, we disagree that these technical details should be provided in a separate proposal, as they are essential for understanding the feasibility of implementing the proposed feature, and are required for meeting the criteria of the Proposed solution section in the proposal template. Please provide an answer to this item.
18.
We are not asking to remove the point from the proposal. We are instead suggesting we no longer need to discuss this comment on the review issue, as we now understand the sentences we questioned in our original comment. Please let us know if you agree.
19.
Similarly to 1, we disagree that these technical details should be provided in a separate proposal, as they are essential for understanding the feasibility of implementing the proposed feature, and are required for meeting the criteria of the Proposed solution section in the proposal template. Please provide an answer to this item.
21.
After re-reviewing the conversation about this item, we believe there was some miscommunication about any impact to the Policy Server. If you could please confirm that the SDL Example Policy Server (https://github.com/smartdevicelink/sdl_server) will not need to be updated to support this feature, and that OEMs do not need to implement a Policy Server to support this feature, we then recommend removing "Policy Server" as an impacted platform.
22.
We believe the following revisions should be made: Add parameter of EcuPower to the VehicleType struct as described in this comment and add information regarding EcuPower included in this comment to the proposal.
Please let us know if you agree.
Agreed Upon Revisions
12.
In Motivation section, change binary size from "177MB" to "16MB".
20.
Remove SHAID as impacted platform.
@theresalech -san
Thank you for your comments.
We left comments below.
The method of making the Mediation App open source and releasing it by each OEM differs greatly from the content of this Proposal, which has been agreed upon by the Motorcycle Subcommittee, so We would like to respond after another meeting of the Motorcycle Subcommittee.
Also, at this point, I would like to discuss the antitrust law separately rather than deciding what to do with it.
・Since SDL Core also has various management functions, it takes a huge amount of man-hours to extract only the necessary functions and develop SDL Core, and maintenance man-hours also become large every time the SDL Core is updated.
・Since the capacity that can be used as SDL in Meter Unit is only several hundred KB, there is a high possibility that it cannot be installed in Meter Unit even if Core for Meter Unit is developed.
・Since there will be a SDL Core in a branch other than the current SDL Core, the management man-hour will increase.
Considering the above, we believe that it is more efficient to take SDL Core into Mediation App.
Since the proposal is in consideration of usability, the access list to the App store will be removed from this proposal.
Add "Video streaming will never work for these low-cost systems based on the design of this proposal" to Potential downsides.
We will answer in 14.
Add about "Video streaming will never work for these low-cost systems based on the design of this proposal" to Potential downsides. "The capacity allocated to SDL components by low-cost Meter head unit varies depending on each OEM, but it is assumed to be about a few hundred KB."
Between SDL Core and communication Protocol included in Mediation App on Smartphone, the communication method via Websocket and JSON rpc will be the same as the current one in order to avoid modification of SDL Core.
The Smartphone Communication Protocol and Meter Unit's Communication Protocol use a lightweight HMI API that sends numerically converted data without using the RPC message of the HMI API as it is.
The image of Proposal is wrong, so replace it with an image like the one attached.
Thank you for your answer that the course of action is correct.
As with the other answers, the details of the function will be proposed in next Phase.
Thank you for your suggestions.
We would like to write the following in Potential downsides.
"This proposal adds the need for every release of Core to be ported to Android and iOS before release to be shipped in the mediation app. This requires a lot of exponential work and time in each release of Core, iOS and Android. Additionally, new features in Core that require dependencies may need to be expected to increase man-hours in each release because of the need to port those dependencies to Android and iOS."
What is the event that breaks the HMI API spec?
Also, why does the HMI API Spec break every release.
If the content is about compatibility, we think the update should be made to hold compatibility
We also agree that we no longer need to discuss this comment.
However, as We commented before, We will revise the description of Generalization to Unification when it is revised.
This will be removed when the Proposal is revised.
We have confirmed that Policy Server is not affected, so we will remove 'Policy Server' from the Impacted platform during the revision
During the 2021-07-27 Steering Committee Meeting, the Steering Committee voted to keep this proposal in review, to allow for further discussion on the review issue.
Theresalech-san
This is from Kuriyama of Suzuki.
As you know, at present, the Board of Directors Nexty is proposing to separate the technical details from the outline content, and discussions are ongoing. and Suzuki supports Nexty's proposal.
Since no conclusion has been reached, we would like to proceed with the discussion on the outline even if the technical details are not answered.
Hi @Takuya-kuriyama -san, without yet having a conclusion from the SDLC Board of Directors, we must continue to follow the current approved SDL Evolution Process, which requires technical details within each proposal. We therefore will wait until all open items on the review issue have been answered and then proceed with the discussion. Thank you.
The Steering Committee voted to keep this proposal in review, to allow the author time to respond to the open items within the comments (1, 2, 3, 6, 7, 9, 10, 17, 19, and 22) and for discussion to continue on the proposal's review issue.
This proposal has been withdrawn per the author's request.