Introduction and Background
After major damage to the electric distribution system, electric utilities in the United States divert all available personnel to restoring service to customers as quickly as possible. In an effort to maximize the time qualified electric line workers spend actually repairing damage, all duties that can be transferred to less-skilled staff will be diverted.
One such role is called either “damage assessor,” “patrol” or “damage survey.” Persons assigned this duty inspect all electric power distribution equipment in the affected area, and report damage back to the area controller. This allows the controller to assign the correct electric crews to damage sites, in the correct priority sequence and with the correct supplies (vehicles, tools and parts) to perform each repair. This last point is critical—each delay while the crews wait for parts or vehicles means additional delay in restoring power to the members of the public.
Because patrollers are generally not trained electric distribution workers (often, they are office workers), they must be trained to recognize and classify damage types and report the damage identified in a way that will enable the area controller to quickly determine what is needed for the specific repair. Current training methods typically involve photographs, and patrol of undamaged areas on “blue sky” days when little or no damage will be seen.
Learning Goals
By creating an immersive, 3D virtual training environment, the learners will be able to practice the skills they will need to perform damage survey in a manner much more similar to the actual environment of job performance. In particular, the simulation will include multiple types of damage, in multiple combinations, viewed stereoscopically or in a 3D rendered environment. It will also simulate the tools available to a patroller, such as binoculars, a tablet PC with specialized software and a built-in camera, and a vehicle.
By emulating the actual procedures that a patroller follows, it is hoped to increase transference of the skills gained to real-world environments. Given unlimited resources, the simulation will eventually include rain, darkness (in which case the tools would include a spotlight) and other obstructions, as well as audio to increase the immersive nature of the simulation.
Another advantage of the virtual training environment is that it will be entirely automated. This will enable just-in-time (JIT) training of patrollers when storm or other major incident damage occurs or is expected. Instructor-led training for patrollers is highly effective, but cannot be held on very short notice, especially since the trainers are often experienced field workers who will be needed in operational roles in emergency situations. It is possible that this learning module would be used as a refresher, for staff who had already received instructor-led training during “blue sky” periods.
The ultimate priority of all training for patrol duty is to ensure the safety of the patroller. This course will include a review of proper Personal Protective Equipment (PPE) and will alert the user to all safety violations, such as encroachment on the Minimum Approach Distance (MAD) to potentially energized electric equipment. Public safety is also of the highest importance, and the patroller will demonstrate the ability to emplace warning devices (cones, warning tape) and when to call for immediate assistance.
Audience
The audience for Damage Survey Training consists of employees of the electric utility who are not employed in operational roles in the electric distribution system. That is, field workers and managers who are responsible for the construction, repair and maintenance of the distribution system as their day-to-day work are not used for survey. That role is taken up by those whose normal duties are elsewhere. Depending on the utility, survey may be performed by office workers from various support departments (finance, training, facilities, legal, marketing, sales) as well as workers from other operational departments whose work can be delayed or suspended during the emergency. If a utility has multiple operational departments in a specific service area (for instance, if they also operate or own the natural gas system) workers from another area may perform patrol in emergencies.
The survey personnel can range from minimum working age (generally 18 in the utility business) to near-retirement age, and in roles including anything from skilled labor (such as meter readers or power plant mechanics) through clerical and professional jobs ranging from accounting to information technology. Generally, engineers are given more technical roles in the restoration, and managers and executives are given supervisory roles.
All patrollers must be sufficiently physically capable to work 12-16 hours per day, and to walk for long distances, since all affected areas must be patrolled on foot to the greatest possible extent.
Office workers will in general have a PC (Windows or Macintosh) assigned to them, which they can use to participate in the training. The field employees would generally have access to at least one PC or tablet per crew, which could be used. Also, patrol teams are increasingly issued a tablet (often an Apple iPad) to use in the performance of their duties, which would then be available for the refresher.
Note that the ideal training environment would be a true immersive virtual space with a dedicated room or theater, stereoscopic glasses, and surround sound. However, since the intent is to have just-in-time training available in the days or hours before an emergency, or even during an emergency, the module must have the ability to degrade gracefully and work in more limited environments such as an office PC.
Tools
It should be noted that the author has some very limited experience in 3D animation development, but none in creating immersive 3D simulations other than supervising a vendor who created several for his employer. He has used none of the tools described in this proposal beyond very brief experimentation as research for this document.
In considering tools for this project, there were three major candidates:
OpenSim
OpenSimulator is the Open Source version of the Second Life 3D immersive environment. OpenSim (an alternate name) has the advantage of portability, in that it can be run on any server and an island or model can be moved from one to another without technical difficulty.
For the purpose of this project, OpenSim offers several other advantages. It is cross-platform, in that it can be used effectively on a Windows PC, Macintosh PC, or a system running Linux. There is a partial Android client as well. It is straightforward to build models in this environment, and there is a truly huge array of preexisting models available both free and commercially. It is also possible to import models created in other 3D modeling software. In addition, OpenSim makes it trivial to create multi-user environments. In fact, that’s all it creates.
For this purpose, OpenSim also has significant disadvantages. One is that it is not trivial to have multiple copies of the same world. That is, if fifty people need to take a course at the same time, which is highly likely for this specific application, it is not trivial to create 50 versions of the same “training island” so that they can all operate independently, and it would be highly disruptive to have them all train in the same world at the same time, since they would all be visible and audible to each other, and their activities would interfere.
Another limitation is that OpenSim doesn’t have a “first-person shooter” mode. For this purpose the ideal would be to have the learner represented by a viewpoint, what 3D environments call a “camera,” with no visible avatar, which is not to my knowledge supported in OpenSim. This author is not highly familiar with the system, but it also seems that scripting is not especially robust.
Finally, a potential issue is that OSSL (the scripting language of OpenSimulator) is considered to be somewhat limited. However, this project does not require complex behaviors from objects, so at least for a prototyping phase (see below) this restriction is not dispositive.
PlayCanvas
PlayCanvas is a browser-based immersive 3D environment. It requires no software installation on any system at any time, beyond a very current (as of September, 2017) browser.
The service offers several advantages. Because it is browser-based it is as cross-platform as currently possible. Any system that can run Firefox 55 or later or current Google Chrome versions, will be able to enter the simulations.
Because models “live” on a server but are not inherently multi-user, a new instance is automatically generated for each participant, avoiding the problems discussed above for OpenSimulator.
As with OpenSim, the server-based nature of the models would make usage across the wide geography of a large company simple. There would be no need to install software on hundreds of client PCs, nor even to set up a server within the company’s wide area network. The model would be hosted on PlayCanvas’ own servers.
PlayCanvas is a service rather than a software package. Free projects cannot be private, and have very limited storage space available. Their lowest paid tier still offers substantially limited storage space. While their pricing is not exorbitant for what is offered, it is a significant barrier to an individual who may only wish to create and use one project.
Since their development environment is restricted to their server, a developer must also worry that if they cease operations (or simply raise prices substantially) one may find oneself “locked in” and unable to migrate to a new platform. The software is Open Source, but it is not obvious that if they exit the market or institute extortionate pricing, another vendor or an Open Source community would step in to keep the service available and affordable.
The PlayCanvas Editor appears to be highly capable, and also highly complex, and would involve a substantial amount of learning for a new developer such as this writer.
Blender
Blender is an Open Source “Swiss army knife” of 3D creation tools. It can create models, render them, includes a physics engine allowing for simulations, and has a very large library of pre-generated models. It can also import models in most significant (non-proprietary) file formats, and likewise export in many formats. It’s cross-platform in several ways: it runs on Windows, Macintosh and Linux systems; its models can be used in its own built-in engine on all those systems (and because it is Open Source, without licensing concerns) and there are third-party ways to turn its models into WebGL JavaScript which can then be viewed in a browser on any system that can run modern web browsers.
In fact, Blender is by a substantial margin the most powerful and capable of the three tools considered here.
The single greatest disadvantage of Blender is its complexity. It is famously difficult to learn and not beginner-friendly. Because it is not inherently browser-based, converting any model generated into a server-hosted version that can be used by multiple learners in multiple physical locations would add yet more complexity. Using any non-web-based model would require installing software on the client PCs, which adds a substantial amount of labor overhead for the presumed utility company that would make use of the model. A version hosted on a server is economically desirable for customers in this situation.
Selected VR Tool
Given the factors above, and given the relatively short deadline for the project and therefore, lack of time to spend on upskilling the sole developer and designer, the author has decided to create a preliminary model in OpenSimulator. A different decision might be made if there were a larger team, or if the author had previous experience with any 3D Virtual Reality development tool.
This decision was made based on economic factors (OpenSimulator development can be done at near-zero cost, with no additional software required), lack of a requirement for third-party WebGL conversion, and the simplicity of the development environment. One potential disadvantage for eventual usage by utilities would be the need to install a client package on each learner machine, such as the Phoenix Firestorm viewer. However, this is less of an objection to its use for prototyping only. Should this become a “real” project intended for actual use in training utility workers in damage surveying, the OpenSimulator version may (depending on experience with it) be treated as a “wireframe” prototype of a real simulation developed in a more specialized and controlled environment.
Given that the sole developer has no familiarity with any of the available tools, and given the time limitation and the developer/designer’s desire to spend significant time on other aspects of the project, such as research and reading, the greater ease of use found in OpenSimulator development renders it highly attractive.
While beyond the scope of this course, given the current state of technology and the author’s analysis of client needs, a final operational version of the training module could be created using either PlayCanvas or Blender (or another tool such as Unity). Because of its unified development, hosting, and viewing environments, PlayCanvas would be this author’s first choice for such a project.
Additional Tools
Given that OpenSimulator will be the primary development tool and learner environment, it is a straightforward choice to use Phoenix Firestorm as the client software. Firestorm is the most popular client for Second Life and is also the client that this author is most familiar with.
Given the availability of so many free or inexpensive 3D models online, and again the time constraints of this project, the author expects to generate few, and possibly no, models ab initio. However, if models do need to be created, it is expected that simpler ones will be produced using the built-in tools of Firestorm within OpenSimulator. If required, models will be “tweaked” using a tool such as SketchUp or Tinkercad. The author may resort to tools such as Blender or even a full CAD program if these simple tools are insufficient, but it is hoped that this will not be necessary as it would add greatly to the difficulty and thus, labor required, to complete the project.
Physical tools required are limited to a single computer, in this case running Debian GNU/Linux on an AMD 8-core CPU (FX 8120) with 8 GB of RAM and an nVidia GEForce GTX 750 video card.
Testing will be performed on this Linux system, and also on a laptop computer running Windows 8.1 and on a virtual PC running Windows 7.0. These will enable testing both on multiple operating systems and multiple screen resolutions. There will be no attempt to test OpenSimulator clients other than Phoenix Firestorm at this prototyping stage.
It is not anticipated that there will be sufficient development time or resources to add audio cues to the simulation by the deadline. If this does become possible, the audio would be obtained from free online sources such as Freesound, and if necessary edited using Audacity, also a free tool. The author is an experienced Audacity editor.
Additional Resources
Note that the author is a trained damage surveyor for a major electric utility, and has experience performing this role in the aftermath of two major tropical storms. As such, no external Subject Matter Expert (SME) will be engaged for this prototyping phase. Should this project become an actual training product to be used to prepare damage surveyors to perform their duties, additional SMEs would participate in the development and review process.