Putting the ‘work’ into ‘AR Workshop’

Deep in the snow of a wintery Chicago, the annual AREA/DMDII workshop was a hotbed of activity!

The sessions attracted around 120 attendees comprising speakers, exhibitors, academics and those representing both commercial AR technology providers and companies using or looking to use AR within their business. Given the rarity of having such a collection of AR practitioners in one place, Glen Oliver (Lockheed Martin) and I wanted to harness this collective brainpower! Together, we represented the AREA Requirements Committee whose remit is to develop a set of industry requirements and use cases to help promote the adoption of AR.

The AREA Requirements Committee strongly believes that in order to benefit the entire ecosystem we need to effectively and impactfully articulate how AR technology can be applied to business problems, what capabilities are needed within AR solutions and, perhaps more importantly, what is the business value of these tools? This will help both vendors and users of AR.

So, with three hours allotted from a precious agenda, how to best use this time? The approach taken was to introduce the importance of developing a linked and connected schema of needs followed by group activities. Here’s what followed:

Backdrop

We began with a summary of the requirements capture, already started at the previous AREA/DMDII workshop. At that session, we captured 96 requirements, split roughly equally between hardware and software. Whilst this was a great start, the outcome resulted in a list of requirements with little context, structure, priority and limited ability to leverage the community to contribute towards them. At the same time, the AREA has collected a number of great use cases which have value to companies wishing to investigate where AR may be applied but the current use cases need more detail to be actionable and linked to derived requirements. More needed to be done!

So, we presented a proposed ‘AREA Schema of Needs, as shown below.

The idea is quite simple. We need to build a hierarchically linked set of needs, in various technology areas, that have bi-directional linkages to the use cases which incorporate the requirements. In turn, the use cases are linked to scenarios which define an end-to-end business process.

These scenarios occur in various settings (including engineering, manufacturing, field service, user operation, etc.) and, ultimately, are relevant in one or more industries (automotive, health care, industrial equipment and other industry verticals).

In order to set the scene, the presenters walked through examples of each of the taxonomy fields. For example, a sample field service scenario was provided as follows:

A field service technician arrives at the site of an industrial generator. They use their portable device to connect to a live data stream of IoT data from the generator to view a set of diagnostics and service history of the generator.

Using the AR device and app they are able to pinpoint the spatial location of the reported error code on the generator. The AR service app suggests a number of procedures to perform. One of the procedures requires a minor disassembly.

The technician is presented with set of step by step instructions, each of which provides an in-context 3D display of the step.

With a subsequent procedure, there is an anomaly which neither the technician nor the app is able to diagnose. The technician makes an interactive call to a remote  subject matter expert who connects into the live session. Following a discussion, the SME annotates visual locations over the shared display, resulting in a successful repair.

The job requires approximately one hour to perform. The device should allow for uninterrupted working during the task.

With the job finished, the technician completes the digital paperwork and marks the job complete (which is duly stored in the on-line service record of the generator).

In this example, the items in blue are links to underlying use cases which need to be supported in order to enable this scenario. Similarly, examples were presented for use cases and requirements needs.

We also introduced the notion of “Levels of Maturity.” This is a useful concept as it enables both users and suppliers of technology solutions to identify roadmap progression, with an eye on future, richer adoption or delivery. Alternatively, not all users of the technology need the most advanced solution now, but they can identify what might make business sense to them in the shorter term.

Group Exercise

With the backdrop complete, we moved into the interactive portion of the session. The audience was split into 17 table groups, each with a mix of people from industrial users, commercial suppliers and academics. The idea was to get a blend of perspectives for the group activity.

Delegates hard at work!

Armed with a set of templates furnished by Glen, the 17 teams were set the following exercise:Delegates hard at work!

1. Choose your industry and setting
2. Provide a written definition of the scenario
3. Highlight the “use case” chunks that form the scenario
4. Describe at least three of the supporting use cases
5. Capture some of the derived requirements/needs
6. Construct a maturity model
7. BONUS: Describe the value proposition of using AR in this scenario

Whilst each team was given a high-level scenario (e.g. “manufacturing operation” or “design review”), they were free to choose their own, if they wished.

It was great to see the level of discussion taking place across all of the tables! One of our objectives for the exercise was to use the outputs from the team as further content for helping populate a future database. However, the primary point of the exercise was to mix the attendees and have them focused on articulating scenarios, use cases and requirements in a structured way that can also be tied back to business value.

At the end of the session, a spokesperson for each team stood up and summarised the results of their work.

Outcome

Each team duly handed in their handwritten efforts, which were transcribed into a more usable digital form and are now available to AREA members by following this link below and opening up the transcription of the group’s outputs:

Augmented Reality Functional Requirements

So, what did we learn?

The teams have supplied an impressive amount of ideas which are summarised in the PDF. One unfortunate aspect of this is that we were unable to capture what were clearly detailed and illuminating discussions that were taking place across all of the tables. In some ways, perhaps, the ability to openly discuss these topics was possibly more valuable to the teams than what was written down.

The scenarios discussed included (but were not limited to) the following:

Additionally, these scenarios were described within a number of industries and settings.

Furthermore, we received some very positive anecdotal feedback from the delegates. One person stated, “This exercise was worth the trip in itself!”

One of the aims of the AREA Requirements Committee is to develop an online database to enable community participation in defining these needs and use cases. This exercise was a great incremental step in that journey. We look forward to building out this model for the benefit of the AR ecosystem and encouraging all to participate.

Acknowledgements

Thanks to the DMDII team for onsite support and to all of the workshop delegates for making this a highly productive exercise.