U.S. Department of
Transportation
Office of the Secretary
of Transportation
Small Business Innovation Research
2003 Program Solicitation
DTRS57-03-R-SBIR
Technical Questions and Answers (UPDATED 04/29/03)
Program Contents
03-RS1 Advanced Sensors for Pipeline System Integrity Management
Question: As we read topic 03-RS1 "Advanced Sensors for Pipeline System Integrity Management" Subtopic 1 - 'pipeline leak detection and location using fiber optic technology', we are assuming that it is envisioned by DOT that the fiber optic cable will be emplaced on and along the length of the pipeline (e.g., 5 to 10 km) for which leak detection is required. Is this true?
Answer: The fiber optic cable technology could be placed along the length of pipeline for above ground pipelines or below ground in new construction applications. In burying a fiber optic cable along an existing pipeline, cost issues will need to be addressed.
Question: Also, as we read topic 03-RS1 "Advanced Sensors for Pipeline System Integrity Management" Subtopic 1 - 'pipeline leak detection and location using fiber optic technology', does the application apply mainly to existing pipelines in which the pipe is already buried, or is it mainly intended for application to new pipelines?
Answer: This topic applies to existing and new pipelines.
Question: Is 03-RS1, Subtopic 1, limited to just fiber optic technologies or would other non-fiber based sensors that provide leak detection and location be considered responsive to the topic?
Answer: Subtopic 1, applies to leak detection and location sensors that are able to interface with fiber optic technologies.
Question: Is 03-RS1, Subtopic 2, visualized to be a temporary system that is used to locate a leak between two defined points along a pipeline between which a leak is suspected, or rather a permanent monitoring system over the entire pipeline leak that is able to detect and locate leaks with a specific length resolution? If the latter is true, what is the length resolution required?
Answer: Subtopic 2, Applications will be considered for either a temporary or a permanent monitoring system. Leak detection location accuracy or specific length resolution would be considered under system performance.
Question: What's the DOT's motivation in not using COTS technology? I.e. is it cost, ease of deployment, maintenance, etc?
Answer: OPS is interested in COTS technologies that were developed for other industries (i.e.: Navy, aircraft or automotive) that could lead to technology break through when applied to the pipeline industry. The technology break through could lead to low cost, ease of deployment or maintenance enhancements.
Question: Must all methods/technologies described in the solicitation be addressed in addition to any new and novel technologies that we may offer? I.e. Is it recommended we discuss and research only our proprietary technology or do we do so in addition to the technologies and methods described in the solicitation?
Answer: The technologies addressed in the solicitation are recommended areas of interest. Applicants are suggested to address the strengths and weakness of their technical approach when compared to other technologies.
Question: Finally, who is the IP owner of any new IP developed under a phase one award? The awardee or the government? Also, what's the status with non-disclosure agreements (NDA')? Can and do awardees ask DOT employees reviewing solicitations to sign NDA's?
Answer: Read the solicitation under section V. Considerations D. Innovations, Inventions, and Patents. http://www.volpe.dot.gov/sbir/sol03/sec5.html this will answer your questions.
Question: We interpret Phase I to be the feasility study for designing an on-line system for leak detection (ie. can in be done? And how?) Is our understanding correct? Are there any expectations in Phase I for participants to provide a demo or working proof of concept if it can be done within the proposed budget of $100,000?
Answer: RSPA would expect some type of proof-of-concept in phase I to support the feasibility study.
03-FR1 A Software Tool for Human Error Investigations in Railroads
Question: Is there a standard operating system in which the proposed software tool is targeted?
Answer: No.
Question: Is there a minimum hardware configuration in which the proposed software tool must execute?
Answer: No.
Question: Is there a standard PDA used by the FRA Office of Safety, railroads, or the National Transportation Safety Board?
Answer: No.
Question: Is there a standard application server used by the FRA Office of Safety, railroads, or the National Transportation Safety Board?
Answer: No.
Question: Is there a requirement for the proposed software tool to integrate with a legacy system?
Answer: No.
Question: Is this topic associated with an ongoing/upcoming Federal Railroad Administration program? We note that the FRA has several ongoing research projects in the human-error domain.
Answer: The FRA has several projects underway that involve human error, but this SBIR topic is not directly related to any of them and is not associated with an upcoming program.
Question: In addition to the criteria in the solicitation, do you have any application domain-specific considerations that you would like to see addressed in the proposal?
Answer: No.
Question: Are there any previous SBIR topics or BAAs that this topic is related to?
If so, could you identify where we could get information on them?
Answer: There are no previous SBIR topics or BAAs related to this topic.
Question: Are there any circumstances that you might want to make us aware of following the submission of the topic (e.g. a new, related initiative; new transition opportunities; new ties to acquisition programs)?
Answer: There are no other circumstances of which inform you.
Question: Do you have any information on the desktop computer system requirements (operating systems, hardware constraints, etc) that the proposed software should comply with?
Answer: No.
Question: The SBIR states that the tool should be compatible with laptop computers in the field. Which operating systems are they using, and are there any hardware limitations we should be aware of?
Answer: FRA issues a variety of laptop computers to field employees. These are all COTS type computers with standard software. The types and operating systems, etc. can be provided to the awardee, as needed.
Question: Do the investigator's laptops and/or handhelds have wireless communication capability?
Answer: I don't know for sure; this can be determined post-award.
Question: The SBIR addresses the possible use of the new tool with PDA's. Do you have any information on the standard PDA's in use by the investigator's such as operating system, makes, etc?
Answer: This can be determined post-award.
Question: The SBIR addresses compatibility with spreadsheets, databases, etc. Are these Microsoft Office programs? If so, do you know which version is in use?
Answer: Microsoft Office is a current FRA standard. Versions vary across the agency as computers are updated.
Question: In addition, compatibility with graphics programs is desired, which graphics program(s) are in use?
Answer: I would structure compatibility at the input. Many graphics and stat programs are capable of taking input from spreadsheets and databases. It is unlikely that FRA would use a graphics or stat program that could not take input from a Microsoft spreadsheet or database.
Question: Likewise, compatibility with statistical programs is also desired, which program(s) are in use (SPSS v10 for example) or another?
Answer: I would structure compatibility at the input. Many graphics and stat programs are capable of taking input from spreadsheets and databases. It is unlikely that FRA would use a graphics or stat program that could not take input from a Microsoft spreadsheet or database.
Question: We are assuming that designers of railroad equipment and systems would also desire to use the new tool, is this a correct assumption?
Answer: The purpose of the tool is to encourage a greater focus on the role of human error in accidents. To the extent that equipment and systems are directly operated by humans, FRA hopes that the designers also consider human error in their designs. There may interest as well on the part of the other transportation modes in the tool.
03-FH1 Visual and Quantitative Representation of Right of Way Land Acquisition Estimates Within Multiple Natural Hazard Environments
Question: Can you please provide some references for the SBIR topic: 03-FH1 Visual and Quantitative Representation of Right of Way Land Acquisition Estimates within Multiple Natural Hazard Environments.
Answer: These references address the nature of problem solving anticipated by the topic. It is expected that a response would take fundamentals to an innovative level.
- http://www.GIS-T.org
- Greene, R.W. (2002) Confronting Catastrophe: A GIS Handbook. ESRI Press.
- Ormsby, T. and Alvi, J. (1999). Extending ArcView GIS: With Network Analyst, Spatial Analyst, and 3D Analyst. ESRI Press.
- Savitsky, B.G. and Lacher, T.E. (1998). GIS Methodology for Developing Conservation Strategies. Columbia University Press.
- Tenchum, A. at Oklahoma State University (1999 TRB study). GIS for Evaluating Socioeconomic Data of Small Communities in Oklahoma. http://rip.trb.org/browse/dproject.asp?n=3015
Question: In which direction is the US DOT or FHWA leaning for Phase 1 of this project? Would they prefer a wide variety of hazards considered now and leave the automation for Phase 2?
Or
Would they prefer an automated application now, leaving the inclusion of many of the event types for Phase 2?
Answer: Phase 1 is best considered for discovery and foundation activity. FHWA is seeking innovation, not replication. The queries are valid but it may not be appropriate to choose from either from our standpoint. If the researcher envisions a tool or process that is dynamically better than those in use, or foresees undeveloped paradigms that should be explored, FHWA does not want to foreshorten that opportunity.
Question: If a model is actually tested on some real data, is there any specific location that US DOT and/or FHWA would like to see ... as an example?
Answer: FHWA does not have a specific location for an example. The researcher can develop a concept that applies to the transportation/environmental circumstances that are local or distant. The researcher is encouraged to seek a network of application/moderator partners where developed theories/processes can be tested. On-going beta testing from a variety of geographic areas can be a component of Phase 1 and Phase 2. Development of a network of awareness and participation is just as important as the development of technical innovation.
Question: Is there a preference for any particular GIS software environment?
Answer: FHWA does not have a preference for a particular GIS software environment. In keeping with broad participation and the opportunity to implement technical aspects, the researcher may want to consider how an optimum number of participants can be engaged in the innovation process.
Question: Is there a preference for off-the-shelf commercial software vs. an application built from scratch?
Answer: FHWA does not have a preference for off-the-shelf software as opposed to a scratch-built application. The premise of SBIR remains innovation and then application. The need to develop baseline software architecture to carry out research ideas may be complicated, and hard to effectively distribute to a network of users, but FHWA should not at this juncture make dampening decisions. If the researcher's concepts require new foundations, then it is up to the researcher to decide how the concepts should be implemented. Phase 1 or Phase 2 are not intended to be sponsored projects but opportunities to introduce and then demonstrate original thinking. The best success from an SBIR topic is universal acceptance and application.
03-FH2 Enhancing the Usability of an Intersection Collision Avoidance Simulation Method
Question: In the solicitation for topic 03-FH2 (Enhancing the Usability of an Intersection Collision Avoidance Simulation Model) it states, "although not required, it would be helpful if you provide a working example to demonstrate your ability to work with Java and user interfaces." My question is about the delivery of the sample code. My firm is not submitting its proposal electronically, and we will probably want to submit sample code. How (and to whom) should we deliver our sample code? Do we submit the sample code electronically?
Answer: They should submit as many copies on CD as they are required to submit paper copies (at least 5). The CD's should be ISO standard CDs that can be read on Windows, Macintosh and Linux machines. If there is executable software, the CDs should state which platform(s) the software will execute on. If there is data (such as Powerpoint Presentations (*.ppt, Microsoft Word (*.doc), *.tiff or *.pcx files, etc, a list of the files, their format and what program(s) will open them should be provided. A statement should be provided that any executables have been virus checked with appropriate virus software from the platform on which the executable is to be run.
* If there is not time to virus check the software, then they should virus check it later and submit a statement to us that it has been virus checked before we open it. (preferably within a week or two as we are not supposed to run executables that are not virus checked)
Question: Is TEXAS a synonym for TSIS?
Answer: No. TEXAS stands for the Texas Experimental and Analytical Simulation Model.
Question: If it is not, can a link be provided (similar to the one for TSIS/CORSIM)?
Answer: No. However, the McTrans Center at http://www-mctrans.ce.ufl.edu/ has some information on TEXAS. Also, the National Technical Information Service has information and background reports on the TEXAS model.
The NTIS web page is located at http://www.ntis.gov/. If you go to this site and do a search on Texas Model for Intersection Traffic you will find a number of background reports on the TEXAS model.
Question: Since this project is to provide a GUI/front-end to TEXAS, will the source code and/or the algorithm itself be made available? If source code is provided what programming language will it be in?
Answer: The concept was that the front end be a standalone program operating independently from the simulation program. This is to minimize the chances of the two programs conflicting with each other. TEXAS is written in Fortran 90 which is a high efficiency engineering language. On the other hand the GUI/front end is proposed to be in a language optimized for user interface and graphics rather than engineering computation. This allows the user to input data on one computer, say a laptop in a classroom, and run the program on another - say a high end engineering workstation. Of course, it also allows both programs to run on the same computer.
Question: Regarding the philosophy of the GPL and copyleft licensing, can a software environment be used for the application development with which the source code will not be provided? For example, application code will be written in a language that will be provided to the DOT, but the source code for the language will be proprietary."
Answer: A legal copy of the compiler and development system used to develop the source code, along with the source code and compiled codes shall be delivered to the government. It shall be up to the offeror to propose and justify the use of whatever compiler and development system is needed.
03-FH3 Fiber Optic Sensor System for Internal Relative Humidity of Concrete
Question: Is the DOT willing to consider only fiber optic moisture measurements?
Answer: This solicitation is limited solely to fiber optic sensors. It should be noted that NSF has announced a major solicitation for all types of sensors.
Question: Would a comparison of fiber optic and MEMS sensor technologies be acceptable under the solicitation?
Answer: Therefore we are not interested in a comparison between fiber optic sensors and MEMS.
Question: Would the ability to also measure pH be desirable?
Answer: A fiber optic sensor that can measure more than one variable would be very desirable, providing this did not compromise its primary function for measuring internal relative humidity.
Question: Does the solicitation 03-FH3 require a fiber optic solution that provides humidity information at discrete locations or is a distributed sensor that runs the length the bridge deck or roadway preferred?
Answer: We are specifically interested in sensors for measuring moisture at discrete locations.
Question: In the second to last paragraph of the above referenced section there are mentions of: Several promising approaches.....have been proposed....and Previous research in fiber optic strain sensors conducted by FHWA... Can you provide any references to these specifically which FHWA has had involvement.
Answer: A description of the FHWA program was given in the July 1999 Issue of Public Roads. It can be found at: http://www.tfhrc.gov/pubrds/julaug99/julaug99.htm. Information about more recent work is given at: http://www.tfhrc.gov/pubrds/02nov/09.htm
Question: Can you elaborate on the tolerance for volume of an individual sensor?
Answer: To be a significant improvement over conventional sensors, the fiber optic internal RH sensor should have a maximum dimension of 1 or 2 millimeters.
Question: The topic description states that the sensor should be entirely self-contained. I assume that the system will permit communication by fiber into and out of the concrete. The objective is to provide continuous monitoring of RH over a period of several years. The description mentions nothing about temperature. Would the temperature be expected to remain roughly constant over time?
Answer: The term "self-contained" was not intended to imply that there would no communication in and out of the concrete. It was meant simply to exclude the need to periodically access the sensor to refill it with chemicals or replace sensing elements. It cannot be assumed the temperature would remain constant over time in concrete. The proposals should explicitly consider temperature compensation for the sensor.
Question: We would very much like to bid this SBIR, however our solution is not fiber optic. My question is would you consider a better solution or are you committed to the fiber optic?
Answer: This solicitation is specifically for fiber optics
03-FH4 Development and Use of Native Plant Sods for Erosion and Sediment Control on Highway Construction Projects
Question: Phase I is for the conduct of feasibility-related experimental or theoretical research. The subject research topic description appears to request actual production quantities of sod for installation on highway construction projects as a final deliverable for Phase I. Is this the intent of this Phase I project? Or is it expected that the developer will break the project into smaller research modules for Phase I, with actual production sod volumes being applied in Phase II?
Answer: You are correct that such development will need to happen in more than one phase. The first phase needs to happen with a literature search, and communication with Universities and/or practitioners in the traditional sod business, native grass establishment, etc. Time will be needed to compare any erosion control techniques and materials that could apply. Yes, phase one could merely be information gathering.....building the CONCEPT -DESIGN.
Question: If the project is awarded in November, 6 months later would be around May. In my state the last frost date can occur between April and May. The project might require a schedule shift into the spring of 2004 to accommodate the native growing season. Is there a possibility to reconcile the funding timeframe with the necessary growing season (if needed) to accomplish the project on schedule?
Answer: Phase II....native seed can be planted any time between May 1 and the first snow (dormant seeding).......they are mostly perennial plants and therefore do not show much above ground the first growing season.....so phase II is likely to take 2 years or 2 summers of experiment with their solution before it is ready to put on a highway slope or in demonstration.
03-FH5 Real Time Linux Operating System Software for Advanced Traffic Controller to Host Traffic Control Software
Question: Do you wish us to develop an API ? The solicitation says "and provide it with an Applications Program Interface (API) suitable for interfacing with current Advance Traffic Controller (ATC) programs."
Answer: No. All real time operating systems (RTOS) have API's. This phrase simply means that the Real Time Linux you develop must present to real time programs running on it an application programming interface which conforms to the standard API being developed by the ATC standards committee. This project is not about developing a new API for advanced traffic controllers distinct from the ATC API. No work on developing a new API for ATCs or enhancing or modifying the ATC API standards should be proposed. Your RTOS must be programmed to meet the ATC API standards.
Question: Where do I obtain information on the API ?
Answer: It is the obligation of proposers to make good use of library and Internet resources. For example, a Google search on ATC, API and Advanced Traffic Controller will reveal the URL
http://www.ite.org/standards/atc/index.asp
The same search will reveal that ITE is planning a course titled
ACTUATED TRAFFIC SIGNALS/ADVANCED TRANSPORTATION CONTROLLER ITS STANDARDS YEAR 2003
An estimated 270,000 traffic signals in the United States have been provided from various manufacturers. These devices do not share a common communications protocol and pose a serious challenge to integration in an ITS environment. Furthermore, they pose a significant burden to many public agencies because of their lack of interchangeability in existing systems. These conditions provide ample incentive for the public-agency marketplace to move forward with traffic signal ITS standards. This course will provide focused information on actuated traffic signals (termed ASC, for actuated traffic signal controllers) for transportation professionals who are planning, designing, procuring, deploying and operating these ITS field devices. The course also will provide the latest information concerning ATC (controller, cabinet and application program interface (API)). NOTE: this course provides about two hours information on the ATC and one hour of information the API. May 8 in Jackson, Mississippi and on May 15 in Destin, Florida. If you wish to sponsor an earlier course, you would have to get 15 attendees.
For more information (ON THE COURSE) please contact James M. Cheeks Jr. at ITE Headquarters (+1 202-289-0222, ext. 131; jcheeks@ite.org).
Question: The implied question is how does one test the prototype on the street at a real intersection in a real controller.
Answer: With regard to how to test/demonstrate the real time Linux - one option which TTI, the University of Idaho and Purdue University as well as other schools have "Controller Interface Devices" which allow real traffic signal controllers to interact with traffic simulation programs without working on street. The kind of demonstration proposed would be up to the offeror.
Question: The implied question is whether traffic engineering expertise is really required.
Answer: The short answer is YES. The traffic engineering expertise is required. There are traffic engineering consulting firms that work with real time software either in the 170 or the Advanced Traffic controller that could be teamed with. Check transportation engineering journals and periodicals.
Question: What are the real-time constraints that we would have to work within?
Answer: Determining this is part of the work of developing a RTOS and is one of the reasons the solicitation states, "This project requires significant experience in traffic engineering, real time control, LINUX and programming of traffic signal controllers."
Question: We feel we should discuss about the "current ATC programs" ( sentence 3 of Technical Description ) with appropriate staff
Answer: Staff of a major city which is interested in or is currently using ATCs such as Tucson, Seattle or Los Angeles might be appropriate. Contact manufacturers - listed in transportation engineering journals and periodicals for lists of cities they have sold to. There are also a number of traffic engineering consulting firms that could be teamed with.
Question: Is documentation for the Los Angeles real time ATC signal control program available?
Answer: A user guide for the local real time ATC signal control program is available. Traffic Signal Control Program (PFD, 772KB)
Question: Can someone enumerate the failures of the standard ( non-real-time ) version of Linux that cause the DOT to request a real-time version?
Answer: Currently, ATCs use commercial real time operating systems rather than Linux.
Question: Has the requestor attempted, or made any significant progress, in this task? What were the results?
Answer: No, this is the first research effort in this area.
Question: Do you want source code as a result of the proposal, or would you accept an adaptation of current realtime linux add ons?
Answer: The solicitation calls for delivery of open source software as a result of the project. Whether source code is included with a demonstration with the proposal is strictly up to the offeror. Whether you adapt current real time Linux add ons or develop new software is up to the offeror to propose and justify.
Question: Is there more material available on the Controller Interface Device?
Answer: Yes, there is. It can be found on the internet using Google.
Question: Would you have an interest in using distributed processors running under Linux?
Answer: The solicitation calls for the software to run with current and proposed ATC controllers. Needs for use of distributed processors would have to be determined from city and state staff who are current or proposed users of ATC controllers and relevant ATC standards.
Question: Is it the intent of this topic to have the real time Linux system developed under this effort directly replace the current RTOS, which we believe is OS-9, that runs on the Motorola MC68360 CPU in the ATC?
Answer: The solicitation says " The ATC does not have an open source real time operating control system." And "This project would adapt an open source Linux for real time applications and provide it with an API suitable for interfacing with current ATC programs." Thus, the project is to provide a standalone open source real time Linux system which can run on current ATCs and support ATC traffic control programs. See also the answers to the other questions on topic 03-FH5.
Question: Clarification: a. Currently ATC programs run directly on hardware. b. You wish to add real-time linux OS to run on hardware. c. The API would be the interface by which the ATC (now a process) would access the hardware, instead of directly accessing the hardware itself.
Answer: No, currently, programs for the ATC run on a real time operating system.
Question: Advanced Traffic Controller (ATC) Programs - These the programs that runs on the hardware at intersections which control the light patterns?
Answer: Yes
Question: In the Phase I section, you talk about the API working with "one commercial real time traffic signal control application"? - Does this mean an ATC program or is this a different application? If it is an ATC, how do we use a program that is compiled to run on the hardware directly? Will we be given source code or a rebuilt binary provided by the commercial vender that uses our API?
Answer: The real time operating system which is produced must run a real time traffic signal control program which is currently being used to control traffic signals. See previous question on Do you wish us to develop an API?
Question: In the description, you talk about "compatibility with API standard under development by the ATC project" - Where is more information about this?
Answer: See previous answer to Where do I obtain information on the API?.
Question: Will you specify a controller that you would prefer that we implement with?
Answer: No. However, it must be one which is commercially available and which is controlling traffic on the street. For further information see answer to The implied question is how does one test the prototype on the street at a real intersection in a real controller.
Question: Will you specify a controller that you would prefer that we implement with? I have a set of linux programs that can do tasks with under a second response times. What sort of response times are you looking for?
Answer: See answer to: What are the real-time constraints that we would have to work within?
Question: I can generate a demo that shows data acquisition and transmission at a nominally real time rate, would you like to see it?
Answer: What kind of demonstrations are provided with the proposal are up to the offeror. However, they should be capable of playing on a computer or standard VCR, CD or DVD and not need staff or special equipment so that all offerors remain on a level playing field.
Question: Is the linux more important then the traffic aspects?
Answer: See answer to The implied question is whether traffic engineering expertise is really required.
Question: What would you like to see on the proposal?
Answer: The requirements are set out on the web in the solicitation documents and the description of the project requirements
Question: Could we talk on the phone?
Answer: All bidders should have the same information provided the same way thus talking on the phone would be unfair other bidders.
Question: Is it the intent of this topic to have the real time Linux system developed under this effort directly replace the current RTOS, which we believe is OS-9, that runs on the Motorola MC68360 CPU in the ATC?
Answer: The solicitation says " The ATC does not have an open source real time operating control system." and "This project would adapt an open source Linux for real time applications and provide it with an API suitable for interfacing with current ATC programs." Thus, the project is to provide a standalone open source real time Linux system which can run on current ATCs and support ATC traffic control programs. See also the answers to the other questions.
Question: Who will provide the target compiler and development tools? Is that up to the bidder?
Answer: It is up to the bidder to suggest and provide the target compiler and development tools. However, one set of the target compiler and development tools must be provided to the government at the end of the project along with copies of the documentation and the open source (GPL) software generated.
Question: We understand that the API has been defined (answered in the question: "Do you wish us to develop an API?"). However, is it a correct understanding that we will need to "implement" the Level 1 Platform Interface API? Will we be provided with a working device driver? Or, will we need to port an existing device driver from OS9 to RT Linux?
Answer: You will need to implement an API which will allow current software to run. You will not be provided with working device drivers. They will be your responsibility.
Question: Recognizing that there are several different target devices available (eg 2070, epac300, etc). Is there a "least common denominator" for the hardware platform that we can expect to be in the field? Such as cpu speed/type, ram limitations, etc?, will we need to port an existing device driver from OS9 to RT Linux?
Answer: The ATC specification provides the "least common denominator" specifications for what you can expect to be in the field. With regard to the CPU type and speed, you should make your software as "cpu agnostic" as possible. Most versions of Linux run on multiple CPU's without code changes.
Question: Are there any cost/licensing restrictions on the flavor of Linux that we determine is appropriate? Does the Linux need to be "free"? Or can a commercially available version be used?
Answer: We would strongly prefer a "free" Linux. We do not wish per unit licensing fees as this violates the basic premises of open source software.
Question: I have a technical question regarding SBIR project 03-FH5. Will the CORSIM software and the CID hardware be provided by the DOT or FHWA or should we include those items in our project budget?Are there any cost/licensing restrictions on the flavor of Linux that we determine is appropriate? Does the Linux need to be "free"? Or can a commercially available version be used?
Answer: They would have to be provided by the offeror. The Linux does need to be a "free" Linux. A version can be provided where the vendor charges for support but the software itself must be free with source code available without licensing costs.
Question: Current commercial real time traffic signal control applications (probably a 0S-9 binary) won't work unmodified on real-time linux. If the commercial application uses the API, it might just need a recompile to work. We would need a recompiled linux binary or the source code to recompile it ourselves. If the commercial application is not yet using the API, then there is a problem.
Answer: According to LA, the current LA ATC software just uses OS9 calls which constitute a preliminary subset of the API. Thus for the Phase I of the project, the Real Time Linux would only have to meet those requirements.
Question: Who will provide the target compiler and development tools? Is that up to the bidder?
Answer: According to LA, the current LA ATC software just uses OS9 calls which constitute a preliminary subset of the API. Thus for the Phase I of the project, the Real Time Linux would only have to meet those requirements.
03-FH6 Computer Design System for Pavement Repair
Question:
Question: Is the current solicitation (03-FH6 Computer-design System for Pavement Repair ) for extension of the previous software developed by DOT known as the Hyperpav? If so, what will be the compatibility requirement for this software? Also if this is not the case, then what are the requirements regarding this? Also the current proposal mentions latest pavement damage crack prediction algorithms available. Where can we get this information? Is there any legacy work done in this area that DOT wants to use?
Answer: No it is not Hyperpave. I have attached the final report that did the intial work on the algorithms for the FEM cracking damage model. SRI Final Report (MS Word, 890KB)
Question: We are currently working on the DOT SBIR topic 03-FH6. We'd like to obtain additional information for latest pavement damage crack prediction algorithms available. If you could point us to the detailed background information, prior art and use model, we'd very much appreciate it. We have great friendly UI design ideas.
Answer: I have attached the final report that did the intial work on the algorithms for the FEM cracking damage model. SRI Final Report (MS Word, 890KB)
Question: From the solicitation (03-FH6) it is not clear which software algorithms should be integrated (for example, NIKE2d, NIKE3d, VESYS, SRIPAVE) in a required user interface. Could you please give more information on this.
Answer: An introduction to VESYS is available. VESYS Model and Software (MS Word, 35KB)
03-NH1 Development of a Restorable Vehicle Occupant Safety System
Question: In regard to SBIR 03-NH1, the RFP states that Phase I proposals "should be based on concepts for utilization of specific hardware and software". Could you please clarify the level of detail you wish to see in the proposal?
Answer: There should be sufficient detail in the proposal so that the evaluator understands completely the design, operation, and testing of the proposed system. The proposers should discuss how and the extent to which their system meets each of the requirements in the RFP. In addition, the proposers should consult the "Proposal Checklist" on http://www.volpe.dot.gov/sbir/hints.html.
Question: In the 2nd bullet of the 3rd paragraph, it says, "A door-mounted airbag made of..." Is this airbag mounted to inflate inside the car or outside?
Answer: The door air bag could be mounted to inflate on the inside or outside of the car.
