3 may 2015 allseen alliance 1 c&c working group meeting 4 june 2014

April 21, 2023 AllSeen Alliance 1

C&C Working Group Meeting

4 JUNE 2014


Antitrust Compliance Notice

• AllSeen Alliance meetings involve participation by industry competitors, and it is the intention of AllSeen Alliance to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of and not participate in any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.

• Examples of types of actions that are prohibited at AllSeen Alliance meetings and in connection with AllSeen Alliance activities are described in the AllSeen Alliance Antitrust Policy. If you have questions about these matters, please contact your company counsel, or if you are a member of AllSeen Alliance, feel free to contact Lee Gesmer or Andrew Updegrove, of the firm of Gesmer Updegrove LLP, which provides legal counsel to AllSeen Alliance.


Guidelines

• This is a reminder that all AllSeen Alliance activities are subject to strict compliance with the AllSeen Alliance By-laws. Each individual participant and attendee at this meeting is responsible for knowing the contents of the AllSeen Alliance By-laws, and for complying with the AllSeen Alliance By-laws. Copies of the AllSeen Alliance By-laws are available at:

• https://allseenalliance.org/allseen/bylaws

• Reminder: This call is being recorded

April 21, 2023 AllSeen Alliance 4 4

1. Review Haier’s updates to the test case specs2. Your Feedback on Homework3. Status of extending “homework” ask to all members4. Review validation tool output

Goals for Today’s Discussion


AllJoyn™ Onboarding Service Framework 1.0 Test Case Specifications changes

• 3.8 Onboarding-v1-08: GetScanInfo() returns results or FeatureNotAvailable error– Expected results added


AllJoyn™ Configuration Service Framework 1.0 Test Case Specifications changes

– 3.1 System app appld equals DeviceID • Test deleted

– 3.9 Config-v1-09: UpdateConfigurations() method with an unspecified language • Test added

– 3.18 Config-v1-18: ResetConfigurations() method with an unspecified language • Test added


AllJoyn™ Control Panel Service Framework 1.0 Test Case Specifications changes• 3.2 ControlPanel-v1-02: Verify all Container

bus objects

– step 6 added

– Expected results added

• 3.3 ControlPanel-v1-03: Verify all Property bus objects

– step 6 added


• 3.4 ControlPanel-v1-04: Verify all LabelProperty bus objects

– step 6 added


• 3.5 ControlPanel-v1-05: Verify all Action bus objects

– steps 6 & 7 added


• 3.6 ControlPanel-v1-06: Verify all Dialog bus objects

– step 6 added


• 3.7 ControlPanel-v1-07: Verify all ListProperty bus objects

– steps 6-12 added


• 3.8 ControlPanel-v1-08: Verify all NotificationAction bus objects

– steps 6-12 added



AllJoyn™ Notification Service Framework Test Case Specifications changes• 2.1 Requirements -- 2nd device added

• 3.3 Notification-Consumer-v1-0403: Invalid language field – expected results added

• 3.5 Notification-Consumer-v1-05: Attributes– New test added

• 3.53.6 Notification-Consumer-v1-06: Custom attributes– Name change added

• 3.7 Notification-Consumer-v1-07: TTL

– New test added

• 4.1 Notification-v1-01: Sending of notifications

– expected results added

• 5.1 Notification-Dismiss-v1-01: dismiss signal– New test added


Feedback:Setup and Run Test Cases


Example: Self Validation Test Setup and Executing Test Cases

1. Configure a Nexus Tablet (Android test device) to connect to Personal Access Point. Nexus 7 Tablet is the device on which the tests are executed

2. Onboard the Device Under Test (DUT) to Personal Access Point. DUT is the device against which tests will be executed

3. Connect the Nexus 7 Tablet to a PC/Laptop (Win 7) via USB cable

4. Download the test code from GIT repository on to PC/Laptop

5. Compile the test code and build test app on the PC/laptop

6. Deploy the test app to the Nexus 7 Tablet

7. Execute command on the PC/Laptop to start the execution of tests on Nexus 7 Tablet against the Device Under Test

8. View and analyze the test results produced on the PC/Laptop

GITGIT

8855

1144

22

66

77

33

DUT


Feedback on Homework from May 7th

• Using the example on previous slide, setup and execute Self Validation Test Cases:– Acquire/configure an Android device (preferably Nexus 7)

– Setup the Test Environment as per Validation Test User Guide

– Compile the test cases as per Validation Test User Guide

– Execute the test cases as per Validation Test User Guide

– Provide feedback on process

• Validation Test User Guide

https://wiki.allseenalliance.org/_media/compliance/alljoyn_validation_test_user_guide.pdf

• Test Code

https://git.allseenalliance.org/cgit/compliance/tests.git/


Your Feedback on self-validation test “homework”

• What your result?

• What was good about the process?

• What should be improved?

• Do you think it is ready to ask our members to try it?

• Note: feedback from LF developer was difficulty building this Android app


Status extending our “homework” ask to all members

1. Need LF to build the Android app self-validation test ? Or reasonable to expect members to build their own Android app?

2. Plan is to email all members (or everyone on mail list?) asking them to do “homework” as a dry run before launching Phase 1.

– If serious bugs / gaps are encountered, can QCE fix them?

3. Send test results and feedback to [email protected]

4. Use “Ask” forum for technical supporthttps://ask.allseenalliance.org/questions/


Validation Tool sample output log


Sample output log from Validation Tool

• from the PC and from Nexus 7 of running a test case. Towards the end the Logcat file indicates if the test case passed– 05-19 12:33:26.570: I/TestRunner(4663): passed: testAbout_v1_01_AboutAnnouncement


Review Haier’s updates to the Phase 2 test case specs

•

• Note: an open item is identifying someone to implement these. It should come from the community. I was told it is bad practice to hire someone to development on open source such as this.


Background from prior meetings


About Feature Test Case Spec

• These test cases evaluate and verify the functionality related to the AllJoyn™ About feature exposed by a device through the About 1.0 interface.

• The About interface is required by an application to provide the discovery mechanism for the service framework interfaces that it supports, as well as providing the basic identification information.

• VOTE to approve “About Feature Test Case Spec” as part of Certification

• Approved on May 7th with stipulations to add s/w release number 14.02 and add ability to use Ethernet connection (section 2.1)

• Document on wiki needs to be updated


Control Panel Service Test Case Spec

• These test cases evaluate and verify the functionality related to the AllJoyn Control Panel service framework 1.0's collection of interfaces.

• These interfaces provide the Control Panel service framework a mechanism to allow for a controller application to render the UI based on the controllee application’s widget metadata.

• Control Panel: Infrastructure for exposing user interfaces for devices remotely

– After receiving a notification that the oven has been on Broil for 5 minutes a user could bring up the oven’s control panel and change the setting to “bake at 250” to keep the food warm

– A user could check the current values of a refrigerator (including current temperature) and modify the settings to make things hotter or colder as needed.

• VOTE to approve changes

• Changes approved May 7th; Tests 1-7 need to be written

• Tests 1-7 need to be added to document on wiki

1 3.2 Suggest to test the signal because of metadata changed Medium Missing

2 3.3Suggest to test the signal because of metadata changed, or because of property's value changed

Medium Missing


4 3.5Suggest to test the signal because of metadata changed, and test the Exec method

High Missing


6 3.7Suggest to test the signal because of metadata changed, and test the "Add", "Delete", "View", "Update", "Confirm" and "Cancel" methods should

High Missing

7 3.8 Suggest to test the signal dismiss High Missing

TypeSerial No. Section # Comments Impact


Notification Service Test Case Spec• These test cases evaluate and verify the functionality related to the AllJoyn Notification service framework when used by an

application to do one or both of the following using the Notification interface:

– Receive (or consume) notifications from other applications

– Send (or produce) notifications to other applications

• The Notification interface is used by an AllJoyn application to send events or state update notifications to other devices connected to an end user's home network, such as a Wi-Fi network.

1Dismiss interface test case

Suggest to add the test case of dismiss interface to see the signal dismiss has the true function of dismissing a notification. Perhaps better to use one test device and two DUTs in this dismiss interface test.

High Missing

2Attributes field test case

Suggests to add the test case of attribute field to ensure the integrity of the field

High Missing

3 3.1Step 5 of the procedure, why the test device promot the tester to "select" the notification text on the DUT? The test device can just promot the tester to "respond", is it OK?

Low Question

4 3.1Step 6 of the procedure, the test device leaves the session. When was the referred session established?

Low Question

5 3.3In expected results, the notification message can still be correctly displayed on the DUT with invalid language field? I think an error message should be displayed.

Medium Question

6 3.5The bullet 4 of the procedure, the "List<attribute>" should be List<customAttributes>?

Medium Incorrect

7 4.1Suggest to add the richObjectPath,richAudioObjectPath and the originalSender in the expected results, to ensure completeness of the attributes field

Medium Missing

8 4.1Step 2, Notification is sessionless signal, don't understand why test device join a session with DUT application?

Low Question

9 4.1Last sentence of expected results, "message bug" should be "message body"?

Low Wording

10 TTL test caseSuggest to add a comparative test case that the test device will not receive the notification when it joins the AP beyond the TTL

High Suggestion


• Notifications: Simple, standardized interface for sending and receiving human-readable messages. “The text message for the Internet of Everything”

– Refrigerator could send a notification that freezer door has been left open for more than 5 minutes

– This could be rendered on any consumer: mobile device, TV, set top box, etc…

– Washing machine can send a notification when wash cycle is complete

• Review Questions



Onboarding Service Test Case Spec

• These test cases evaluate and verify the functionality related to the Onboarding service framework exposed by a device through the Onboarding 1.0 interface.

• The Onboarding interface allows an onboader to send the Wi-Fi credentials to the onboardee to allow it to join the personal access point.

• Onboarding: Provides a standard way to get devices onto a Wi-Fi Network (Wi-Fi is needed)

• Review Questions

• VOTE to approve changes1 3.2

What is meant by "the channel switching feature" in step 10? What happens if the DUT does not support this feature and the DUT successfully join the WiFi AP after executing the Connect() method on the DUT's Onboarding bus object? The test case exits (i.e. DUT just joins the WiFi AP and exits the softAP mode without any connection state feedback to the test device)?

Low Question

2 3.8

In expected results, Age of the scan information in minutes is missing for the first sub-item of the last bullet. When the test device calls the GetScanInfo() method on the DUT's Onboarding bus object, both scanList and scan information age are returned.

Medium Missing

3 3.8In the expected results, Authtype is missing for the second sub-item of the last bullet. Both SSID and authType are included in the scanList.

Medium Missing



Configuration Test Case Spec

• These test cases evaluate and verify the functionality related to the AllJoyn™ Configuration service framework exposed by a device through the Config 1.0 interface.

• The Config interface is a secure interface that provides the functionality to perform device-specific configuration and actions. It is expected that an OEM's developed application for the device (referred to as the System App) will bundle this service framework.

• Configuration: Enables ability to set configurable persistent values

– By default allows for a “Friendly Name” to be set. This name provides an end user the ability to specify a string that they can associate with the product, i.e. “Living Room TV”, “Patio Speaker”, "Garage Refrigerator" etc.


Author Reviewer

1 3.1 Config-V1-01Since this requirement (AppId of the DUT’s System App matches the DUT’s DeviceId) is not necessary in the interface specification, suggest to delete this test case

Low Suggestion

2

Test case of UpdateConfigurations() method with the unspecified language

Suggest to add a test case about UpdateConfigurations() method with the unspecified language

High Missing

3

Test case of ResetConfiguration() method with the unspecified language

Suggest to add a test case about ResetConfiguration() method with the unspecified language

High Missing

TypeSignature

Serial No. Section # Comments Impact


C&C Working Group Information

• To access the wiki page please go to https://wiki.allseenalliance.org/compliance/overview

• To contact the Certification and Compliance Work Group, send an email to the [email protected]

• To join the Certification and Compliance Work Group Mailing List, please self-subscribe at https://lists.allseenalliance.org/mailman/listinfo/allseen-cc.

• C&C WG meetings every week– The meeting will be held on:

– Wednesdays 20:00PM - 21:00PM Eastern Time

– Wednesdays 17:00PM - 18:00PM Pacific Time

– Thursdays 9:00AM - 10:00 AM Korea/Japan

– Thursdays 1:00AM - 2:00 AM France


Thank youFollow us on

For more information on AllSeen Alliance, visit us at: allseenalliance.org & allseenalliance.org/news/blogs

3 may 2015 allseen alliance 1 c&c working group meeting 4 june 2014

Documents