Commander 5 EV
Tracks and Wheels is a manufacturer and supplier of underground mining equipment. The primary business of the company is modifying and designing utility vehicles for use in mines throughout Canada. Recent shifts in the utility vehicle market have been towards electric vehicles, and in order to remain a market leader Tracks and Wheels has developed an electric vehicle based on the existing Commander 5 platform.
From a project management perspective my primary goal for the Commander 5 EV was to define the user interaction flow, and ensure vehicle systems were designed properly. From a programming and controls perspective the goal was to develop a well architected software system which would provide control to all vehicle subsystems.
Tools and Technologies
Solution and Process
From a project management perspective the process I undertook was systematic and collaborative. Upon discussing functional aspects of the electrical and control systems with each team member it became clear that there were no clear functional requirements set for the electrical systems. In order to move forward with electrical and software systems design a set of requirements would be needed.
To determine functional requirements of the electrical systems I scheduled and facilitated bi-weekly meetings for one full month. During each meeting all six members of the engineering team would discuss the desired functionality of one specific system on the vehicle. Most meetings were primarily influenced by an expert, a member of the team with intimate knowledge about the specific subsystem of the vehicle. After an initial explanation of the system under analysis and a brief overview of the goal of the meeting an organic conversation would take place. The conversation would be guided towards how best to define the requirements so that the system would perform all required tasks.
The result of each meeting was a shared understanding within the engineering team about functionality expected from each vehicle system, as well as a set of functional requirements for that subsystem. Functional requirements obtained from each meeting were recorded in a master document and referred to during the design phase of each system.
From a software architecture and control system perspective subsystem decomposition was used to break down functional requirements into constituent parts small enough for individual implementation. Software architecture design for the vehicle controller was based on the functional requirements defined in the engineering team meetings. Based on these requirements a software architecture was designed and implemented which performed control operations on each vehicle subsystem, while also effectively allowing for user interaction.
During the engineering team meetings I often took a top-down approach, asking "What does the user see/do when interacting with this vehicle system?". I think this approach was helpful both from the perspective of creating meaningful requirements, but also for improving the thought process of the team by constantly considering the end user. Asking this simple question often made the answer to questions obvious, since the system should always allow the user to perform their job efficiently with minimal frustration.
Another observation that I made during the team meetings was that disagreement often lead to positive outcomes. Although disagreements between team members are sometimes tough to resolve, especially when occurring between intelligent individuals with differing viewpoints, they give the opportunity to investigate the thought process of another team member. This opportunity can be extremely valuable in understanding complex technological systems as well as working towards a better understanding of user requirements.
Enjoying these posts? Subscribe for moreSubscribe now
Already have an account? Sign in