Publications

10 Results
Skip to search filters

Technology Performance Level Assessment Methodology

Roberts, Jesse D.; Bull, Diana L.; Malins, Robert J.; Costello, Ronan P.; Babarit, Aurelien B.; Nielsen, Kim N.; Ferreira, Claudio B.; Kennedy, Ben K.; Dykes, Kathryn D.; Weber, Jochem W.

The technology performance level (TPL) assessments can be applied at all technology development stages and associated technology readiness levels (TRLs). Even, and particularly, at low TRLs the TPL assessment is very effective as it, holistically, considers a wide range of WEC attributes that determine the techno-economic performance potential of the WEC farm when fully developed for commercial operation. The TPL assessment also highlights potential showstoppers at the earliest possible stage of the WEC technology development. Hence, the TPL assessment identifies the technology independent “performance requirements.” In order to achieve a successful solution, the entirety of the performance requirements within the TPL must be considered because, in the end, all the stakeholder needs must be achieved. The basis for performing a TPL assessment comes from the information provided in a dedicated format, the Technical Submission Form (TSF). The TSF requests information from the WEC developer that is required to answer the questions posed in the TPL assessment document.

More Details

Systems Engineering Applied to the Development of a Wave Energy Farm

Roberts, Jesse D.; Bull, Diana L.; Costello, Ronan P.; Babarit, Aurelien B.; Nielsen, Kim N.; Ferreira, Claudio B.; Kennedy, Ben K.; Malins, Robert J.; Dykes, Kathryn D.; Weber, Jochem W.

A motivation for undertaking this stakeholder requirements analysis and Systems Engineering exercise is to document the requirements for successful wave energy farms to facilitate better design and better design assessments. A difficulty in wave energy technology development is the absence to date of a verifiable minimum viable product against which the merits of new products might be measured. A consequence of this absence is that technology development progress, technology value, and technology funding have largely been measured, associated with, and driven by technology readiness, measured in technology readiness levels (TRLs). Originating primarily from the space and defense industries, TRLs focus on procedural implementation of technology developments of large and complex engineering projects, where cost is neither mission critical nor a key design driver. The key deficiency with the TRL approach in the context of wave energy conversion is that WEC technology development has been too focused on commercial readiness and not enough on the stakeholder requirements and particularly economic viability required for market entry.

More Details

Guidance on the Technology Performance Level (TPL) Assessment Methodology

Roberts, Jesse D.; Bull, Diana L.; Weber, Jochem W.; Babarit, Aurelien B.; Costello, Ronan C.; Neilson, Kim N.; Kennedy, Ben K.; Malins, Robert J.; Dykes, Katherine D.

This document presents the revised Technology Performance Level (TPL) assessment methodology. There are three parts to this revised methodology 1) the Stakeholder Needs and Assessment Guidance (this document), 2) the Technical Submission form, 3) the TPL scoring spreadsheet. The TPL assessment is designed to give a technology neutral or agnostic assessment of any wave energy converter technology. The focus of the TPL is on the performance of the technology in meeting the customer’s needs. The original TPL is described in [1, 2] and those references also detail the critical differences in the nature of the TPL when compared to the more widely used technology readiness level (TRL). (Wave energy TRL is described in [3]). The revised TPL is particularly intended to be useful to investors and also to assist technology developers to conduct comprehensive assessments in a way that is meaningful and attractive to investors. The revised TPL assessment methodology has been derived through a structured Systems Engineering approach. This was a formal process which involved analyzing customer and stakeholder needs through the discipline of Systems Engineering. The results of the process confirmed the high level of completeness of the original methodology presented in [1] (as used in the Wave Energy Prize judging) and now add a significantly increased level of detail in the assessment and an improved more investment focused structure. The revised TPL also incorporates the feedback of the Wave Energy Prize judges.

More Details

WEC Farm Functions: Defining the Behaviors of the Farm

Bull, Diana L.; Costello, Ronan C.; Babarit, Aurelien B.; Malins, Robert J.; Kennedy, Ben K.; Neilson, Kim N.; Bittencourt, Claudio B.; Weber, Jochem W.; Roberts, Jesse D.

Capabilities and functions are hierarchical structures (i.e. taxonomies) that are used in a systems engineering framework to identify complimentary requirements for the system: what the system must do to achieve what it must be. In the case of capabilities, the taxonomy embodies the list of characteristics that are desired, from the perspective of the stakeholders, for the system to be successful. In terms of the functions, the hierarchy represents the solution agnostic (i.e. independent of specific design embodiments) elements that are needed to meet the stakeholder requirements. This paper will focus on the development of the functions. The functions define the fundamental elements of the solution that must be provided in order to achieve the mission and deliver the capabilities. They identify the behaviors the farm must possess, i.e. the farm must be able to generate and deliver electricity from wave power. High-level functions are independent of the technology or design used to implement the function. However, detailed functions may begin to border on specific design choices. Hence a strong effort has been made to maintain functions that are design agnostic.

More Details

Systematic Literature Review: How is Model-Based Systems Engineering Justified?

Carroll, Edward R.; Malins, Robert J.

The genesis for this systematic literature review was to search for industry case studies that could inform a decision of whethe r or not to support the change process, investment, training, and tools needed to implement an MBSE approach across the engineering enterprise . The question asked was, how the change from a document - based systems engineering approach (DBSE) to a model - base d systems engineering approach (MBSE) is justified? The methodology employed for this systematic literature review was to conduct a document search of electronically published case studies by authors from the defense, space, and complex systems product eng ineering industries. The 67 case studies without metrics mainly attributed success to completeness, consistency, and communication of requirements. The 21 case studies with metrics on cost and schedule primarily attributed success to the ability of an MBSE approach to improve defect prevention strategies. The primary conclusion is that there is a significant advantage to project performance by applying an MBSE approach. An MBSE approach made the engineering processes on a complex system development effort m ore efficient by improving requirements completeness, consistency, and communication. These were seen in engineering processes involved in requirements management, concept exploration, design reuse, test and qualification , Verification and Validation , and margins analyses . An MBSE approach was most effective at improving defect prevention strategies . The approach was found to enhance the capability to find defects early in the system development life cycle (SDLC), when they could be fixed with less impact a nd prevented rework in late r phases , thus mitigating risks to cost, schedule, and mission. However, if a program only employed an MBSE approach for requirements management , a dvantages from finding defects early could not be leveraged in later phases , where the savings in cost and schedule from rework prevention is realized. Significant performance success was achieved when the systems engineer (SE) held a leadership role over engineering process es. A number of the case studies addressed a general lack of sk illed MBSE engineers as a major hindrance to implementing an MBSE approach successfully .

More Details
10 Results
10 Results