2018 LOA Symposium

Small Business Innovation Pavilion

As part of LOA’s strategic plan, we want to inspire and inform our members about how small businesses are innovating and solving problems. LOA is offering certified Small Businesses (WOSB, SDVOSB, HubZone, 8a, etc) an opportunity to be a part of a Small Business Innovation Pavilion (SBIP) at the Symposium. Qualifying companies will receive a 10 x 10 booth at a 20% discount over the standard booth pricing and 2 complimentary exhibitor passes.

Selected companies will be invited to pitch their innovation in front of a distinguished panel of senior leaders.

Criteria to be located in the Pavilion:
1) Certified Small Business verification
2) Applicants must provide a one page summary that highlights how your company uses innovation to solve problems in Logistics and/or the Aerospace Defense Industry
3) Acknowledge that if selected, your booth will be located within Pavilion during Exhibit Hall hours.

Problem Statements
Does your company offer a solution to challenges faced by the logisitics community and the DoD? Check out the Problem Statements below.

Click on the button below to begin the application.

SBIP APPLICATION

For questions, please contact Jondavid DuVall, JD@loanational.org.

Deadlines:

Innovation Pavilion applications deadline: August 31, 2018
Notifications sent to applicants the week of: Setember 1, 2018
Applicant deadline to accept invitation: September 7, 2018

Are you a startup and still incubating? We can offer you a reduced registration rate as well to attend and network! Just ask us how.

Problem Statements

Mobile and Home station Wireless Flightline (More Information)

Category: CIO

Problem Statement: Many home station and deployed flightlines have transitioned to mobile maintenance devices but are not truly mobile as they are not supported by a secure wireless network. Today, once a maintainer has completed a maintenance task they are required to walk back into the maintenance unit and log onto a workstation, or “dock” the device to complete the task. This action takes time away from the maintainer to conduct hands on maintenance. Also this action introduces opportunities for data corruption. For example, if a technician has to enter the serial number of an old removed component and a newly installed component, they rely on transcribed information from paper to input it into the database. This could result in inaccurate data entries. If they had the ability to access the information at the point of maintenance it would increase maintenance touch time and reduce erroneous data input.

Intended Outcome: In responding to this problem statement, the paper shall propose a plan for developing a secure deployable and home station wireless network that is device agnostic.
Assumptions: The proposal should not make assumptions.

(less)


Automate manual F-35 readiness Rates (More Information)

Problem Statement: The F-35 Sustainment Performance Management System (SPMS) is a manually dependent fleet readiness reporting system. Twice daily, Maintenance Operations Center technicians or Lockheed Martin Site Leads have to manually gather data and e-mail the F-35 Operations Center. This data is manually input into SPMS, which calculates aircraft availability and mission capable rates. If the aircraft is not serviceable additional information has to be input detailing what condition is driving the non-fully mission capable status. The manual data input action introduces opportunities for data corruption. The F-35 Autonomic Logistics Information System (ALIS) needs the capability to provide an autonomic means to collect and aggregate Air Vehicle Availability Rate (AVA), Mission Capable Rate (MC), Fully Mission Capable Rate (FMC), and Mission Effectiveness Rate (ME) in addition to other data points used to calculate fleet status.
Intended Outcome: In responding to this problem statement, the paper shall propose a plan for developing an automated aircraft availability reporting system.
Assumptions: Developer would have access to the reported data.
(less)


DevOps for DoD Information and Weapons Systems (More Information)

Category: Cyber
Problem Statement: Sustainment of weapons system and information system software in the Department of Defense (DoD) has been problematic from its inception. In the early days, it was not unusual for either software development or sustainment activities to require more than twice the estimated cost or schedule. While there are many factors contributing to this condition, it is largely due to the “waterfall” method of updating software, which necessitates the definition of all requirements up front, along with a complete and approved design, before coding can even begin. Rigorous testing of each level of code, design, and requirements and the bottom of this waterfall takes a long time to accomplish, and when defects are found, more schedule is needed to go back “up the waterfall” to fix problems then re-test the product to assure that no unintended factors are introduced. If real world requirements change during an update (and they always do), software production pauses while new requirements are estimated and added to the software release. This slows down the release cadence, increases expense, and amplifies the likelihood of unintended consequences, such as new defects, which would again require a re-visit of the waterfall to fix and test.
Industry best practices have moved beyond this waterfall approach and have become more agile and suited to the end user’s wants and needs. One approach that focuses on short (e.g., two-week-long) update cycles is called DevOps. The word DevOps is combination of the words “Development” and “Operations.” As the name suggests, it brings the operational environment and the end user into the software update arena, getting instant feedback from the operators and applying it to the requirements for the next release. Software developers work on the most critical items first, apply quality development techniques and automatic testing to perform the update without sacrificing quality. In most cases, this development happens on the fielded system, so that new features or fixes can simply be “toggled on” as deployment. This rapid update and release cycle also allows the fielded product to keep pace with cybersecurity and information assurance requirements, which change daily to keep pace as new threats and vulnerabilities in the software are uncovered.

However, this rapid DevOps approach is not a great fit for traditional DoD acquisition practices. DevOps eschews defining all requirements up front, acknowledging that not all requirements can be known at the beginning of an update. Traditional milestones such as the System Requirements Review (SRR), Preliminary Design Review (PDR), Critical Design Review (CDR), and Test Readiness Review (TRR) are no longer needed, replaced by continuous customer collaboration, continuous integration of updates, and automatic testing. Software is deployed daily once it has passed through the automatic checks of the update “pipeline”, and fielded system becomes the system of record. What is needed is a thoughtful approach to implement DevOps in organic DoD software sustainment, including Information Assurance and Cybersecurity scans, as well as all acceptance testing and certifications.

Intended Outcome: In responding to this problem statement, the paper shall propose a plan for developing an approach for DevOps in a DoD organic sustainment organization. The paper author shall focus their approach on information systems hosted in a secret or top-secret cloud, using Platform as a Service (PaaS). At a minimum, the paper shall address the following topics:
*Requirements generation and tracking
*Rapid release cycles
*Automatic software builds
*Automatic unit, integration, system, and acceptance testing
*Quality practices
*Software maintenance metrics
*Integration with the DoD Acquisition model
*Integration with the IA, Cybersecurity, and Testing community (e.g., DISA, 46th Test Squadron)

Assumptions: The paper shall make the following assumptions in responding to the Problem Statement:
Modern programming languages and Integrated Development Environments (IDEs) will be utilized
The products will be information systems that can be hosted on a secure cloud using PaaS or similar environments.
Approaches that also include embedded weapon systems would be welcomed, but are not required.
(less)


Strengthening Supply Chain Across International Boundaries (More Information)

The DoD supply chain is expansive and crosses national boundaries. How do we ensure consistent supply of key materials to repair and sustain DoD capabilities in peacetime and contingency operations? For example, a key component for Joint Service Lightweight Integrated Suit Technology can only be found in Germany. How do we develop predictive capability that accounts for disruptions in international supply chains so that the Air Force can adjust and minimize the impacts of these disruptions?

Assumptions: No assumptions should be made
(less)


Supply Chain Flexibility to Expand and Contract Capacity and Capability (More Information)

How do we as a DoD invest or develop supply chains that can rapidly expand and contract to meet Service priorities, whether contingencies or increases in training? In fiscally strained environments and the need for rapid engagements, how do we account for supply chain availability? Current supply chains provide capabilities 12-18 months after investment, but future contingencies and even peacetime requirements require a much faster rate of return on investment.

Assumptions: No assumptions should be made
(less)


Optimization of Supply Chain Management (More Information)

Distribution Management within the Air Force Supply Chain is split between multiple organizations across the Air Force preventing unity of effort and focused, coordinated transportation management and policy to enhance movement of assets to warfighters.
The Air Force requires capability that links the source of supply with distribution functions in order to optimize and facilitate velocity of asset movement.

Assumptions: No assumptions should be made
(less)