• Home
  • Development Approach

Development Approach

Nutron­ics, Inc. uti­lizes a devel­op­ment approach, illus­trated in Fig­ure 1, that works to max­i­mize per­for­mance while min­i­miz­ing risk and cost.  Our approach focuses on min­i­miz­ing the risk and cost asso­ci­ated with indi­vid­ual com­po­nents or assem­blies by empha­siz­ing the use of commercial-off-the-shelf (COTS) com­po­nents as much as pos­si­ble.  An addi­tional tool we uti­lize to min­i­mize risk and cost is exten­sive use of mod­el­ing and sim­u­la­tion to eval­u­ate the impact of var­i­ous design deci­sions.  The devel­op­ment approach descrip­tive fig­ure includes two color-coded types of boxes: Sil­ver boxes rep­re­sent “exter­nal” con­straints (the mis­sion is defined by the cus­tomer, sys­tem level capa­bil­i­ties are defined by exist­ing or real­iz­able sys­tem solu­tions, and low level data is defined by com­po­nents or test­ing) while sand-colored boxes rep­re­sent flex­i­ble devel­op­ment processes that give space for cre­ative prob­lem solv­ing to match the cus­tomer require­ments to a min­i­mum cost and risk solution.

Our devel­op­ment approach starts by work­ing closely with the cus­tomer to iden­tify and under­stand the mis­sion or prob­lem state­ment and trans­late the related objec­tives into require­ments and a can­di­date top level solu­tion approach.  We attempt to match the cus­tomer require­ments with a top-level solu­tion / sys­tem that either exists or is real­iz­able with low to medium risk.  The next step is def­i­n­i­tion of detailed require­ments for the sys­tem – these will include the num­ber of actu­a­tors, actu­a­tor spac­ing, tem­po­ral band­width (at a spec­i­fied gain mar­gin), opti­cal require­ments over a wide cap­ture field of view and nar­row oper­a­tional field of view, and other require­ments that are crit­i­cal for high per­for­mance AO systems.

The reader will note that the require­ments for an AO sys­tem in our devel­op­ment process fall in the “Sys­tem Require­ments Def­i­n­i­tion” block and are typ­i­cally defined by Nutron­ics, Inc. through inter­ac­tion and trade stud­ies to meet mis­sion require­ments with the cus­tomer.  This ini­tial require­ments def­i­n­i­tion process is opti­mal to pro­vide the cus­tomer with the best under­stand­ing of how to meet the mis­sion require­ments.  Our exten­sive mod­el­ing and sim­u­la­tion tools (for more infor­ma­tion about Barchers Covari­ance Code – BCC – and Barchers Wave Optics Code – BWOC – please read here) pro­vide the cus­tomer with the max­i­mum pos­si­ble infor­ma­tion regard­ing the require­ments devel­op­ment and allow the cus­tomer to pro­ceed from this ini­tial phase with con­fi­dence.  This approach also lends itself to a multi-phased pro­cure­ment process wherein the require­ments devel­op­ment process con­sti­tutes the ini­tial phase and the design, devel­op­ment, and integration/test phase fol­lows.  In some cases the cus­tomer will have already devel­oped AO sys­tem require­ments and we are always happy to work with cus­tomers in this sit­u­a­tion, how­ever, the given require­ments def­i­n­i­tion may include even just one or two require­ments that a cus­tomer does not real­ize have a tremen­dous impact on sys­tem cost or risk but may in fact be non-mission crit­i­cal.  We believe that by work­ing with the cus­tomer in the ini­tial require­ments def­i­n­i­tion phase we can help min­i­mize the customer’s cost and risk and define the opti­mal solu­tion path.

High per­for­mance AO sys­tems that oper­ate in a reli­able man­ner have a large num­ber of com­plex and inter-related require­ments.  The inter­ac­tions between com­po­nents are often sur­pris­ing and non-intuitive – and our knowl­edge and under­stand­ing of these inter­ac­tions is cap­tured in our sys­tem spec­i­fi­ca­tions.  The know-how related to devel­op­ment of high per­for­mance AO sys­tems has tremen­dous value and should not be over­looked by cus­tomers who have a mission-driven need for a high per­for­mance AO system.

Fig­ure 1: Nutron­ics, Inc. Devel­op­ment Approach.  Sil­ver boxes rep­re­sent “exter­nal” con­straints (the mis­sion is defined by the cus­tomer, sys­tem level capa­bil­i­ties are defined by exist­ing or real­iz­able sys­tem solu­tions, and low level data is defined by com­po­nents or test­ing) while sand-colored boxes rep­re­sent flex­i­ble devel­op­ment processes that give space for cre­ative prob­lem solv­ing to match the cus­tomer require­ments to a min­i­mum cost and risk solution.

 

© 2012 NAO Systems
Website by iSupportU