Summary
Commission a baseline timing review and configuration verification before selecting a comparison schedule for the proposed Lima SOLARTODO smart-traffic pilot. Preserve existing operating records, document any preliminary retiming separately, and compare the verified candidate strategy with a clearly defined background plan.
Consider randomized comparison periods only if the selected configuration, operating authorization, state records, and recovery arrangements support them. The supplied evidence establishes neither a Lima deployment nor an exact product model or expected improvement.
Key Takeaways
- Preserve timing plans and operating records before changing settings; check that they describe actual operation.
- Review timing quality and record any preliminary retiming as a separate intervention.
- Define the evaluation boundary, operational objective, measures, and exclusions before comparison collection.
- Verify candidate functions, authorized switching, state records, and recovery before considering randomized periods.
- Confirm a collection method for every measure; catalog components do not establish data access or export functions.
- Obtain the authoritative product PDF, exact model, applicable pages, and operating conditions before selecting a configuration.
Proposed problem
The buyer needs to distinguish the candidate control strategy’s contribution from differences associated with background signal-timing quality.
FHWA’s validation guidance, Chapter 1 explains that the quality of comparison timings affects assessments of adaptive control. It also distinguishes verification of requested features from validation against operational objectives.
The supplied pack contains no Lima timing records or observations establishing whether existing timings need improvement. For this proposal, preserve separate records for existing operation, any revised background plan, and the candidate strategy. If the timing review supports no changes, existing operation and the reviewed background plan may be identical.
Source-backed product boundary
The supplied extraction, catalog identity city-catalog-2026-11-01-v1, describes SOLARTODO smart traffic as combining a traffic pole, camera, radar, signal equipment, and edge processing. It establishes an equipment family for traffic perception and control. Product navigation: SOLARTODO smart traffic. Supplied public source: smart-traffic catalog.
The extraction does not establish a particular adaptive algorithm, comparison mode, controller compatibility, historical export function, detection accuracy, latency, or installed configuration. Pole geometry, dimensions, sensor selection, and signal interfaces require the selected configuration.
No product PDF, PDF URL, exact model, PDF page reference, or model-specific operating conditions were supplied. These remain unresolved procurement inputs; this article recommends no substitute model or specification.
The FHWA adaptive signal control FAQs describe adaptive control generally as collecting current demand information, evaluating performance, and adjusting signal timing. That description does not establish those functions in the offered SOLARTODO configuration.
Proposed baseline and comparison schedule
The following arrangements are proposals for the buyer to evaluate, rather than documented SOLARTODO functions or Lima operating requirements.
Preserve and review existing operation
Request the timing plans used during observation, plan identifiers and effective dates, scheduled changes, relevant controller settings, and operator intervention records. Check the documents against observed operation and agree a timestamp convention.
Define the movements, links, and routes included in the evaluation. State which effects outside that boundary will remain unmeasured. Record operating conditions alongside outcomes.
Commission a timing-quality review without assuming that retiming is necessary. Preserve the original records and document the evidence supporting any proposed change.
Separate preliminary retiming from the strategy comparison
If the responsible operator authorizes retiming, record the revised settings, rationale, and effective dates. Keep observations under the original operation distinguishable from those under the revised background plan.
Where observations permit, report the preliminary retiming comparison separately from the candidate-versus-background comparison. Examine differences in demand, operating conditions, and data collection before attributing observed changes to either intervention.
During comparison collection, retain a versioned definition of the background plan. Record necessary changes and decide whether affected observations need a separate analysis stage.
Make randomization conditional
First verify the candidate strategy in the selected configuration and confirm an authorized process for restoring the background plan. Request configuration-specific evidence of switching behavior, operating-state records, operator responsibilities, and recovery procedures.
FHWA Chapter 1 describes a Mesa field study that randomly distributed background-operation days through its test period. That historical study supports discussion of the method; it establishes neither a Lima schedule nor SOLARTODO switching capability.
For the proposed Lima evaluation, consider interspersed randomized periods only after those prerequisites are resolved. Before allocation, define operating categories, period boundaries, transition handling, and how planned operation will be reconciled with actual operation. Record schedule departures.
If controlled switching is unavailable, consider a prespecified matched-period comparison. Document matching criteria, observed differences, and limits on attribution. Matching should not be represented as equivalent to random allocation.
The supplied evidence establishes no Lima pilot duration, period length, or sample size. Determine these through an agreed evaluation plan informed by baseline observations, data completeness, and operational constraints.
Select measures with obtainable data
FHWA Chapter 1 links operational objectives to measures and data sources, including travel-time observations, counts, and signal timing and detector records.
For this proposal, select the operational objective before choosing measures. Route travel time is a possible outcome only if suitable observations can be collected consistently across operating states. Add secondary measures only when each answers a defined buyer question and has a verified collection method.
Catalog references to cameras, radar, and edge processing do not establish access to trajectories, synchronized counts, phase histories, or analysis-ready exports. Confirm data definitions, timestamps, access, and completeness before including a measure.
Use consistent collection and analysis methods across states. Report missing observations, uncertainty, operating conditions, interventions, and protocol departures alongside estimated differences. Examine the agreed movements as well as any route-level summary.
Proposed acceptance decisions
Before outcome analysis, agree:
- The configuration features to verify and the evidence required for each.
- The operational objective and evaluation boundary.
- The observations and analysis methods supporting the comparison.
- The treatment of transitions, interventions, missing data, and background-plan changes.
- The evidence needed to accept the configuration, request further observation, or record an inconclusive outcome.
The supplied pack provides no product-specific numerical improvement threshold. If the buyer later adopts an acceptance threshold, document its basis and distinguish it from any supported product claim or measured result.
Survey and procurement checklist
Before specifying equipment, confirm the proposed evaluation boundary and responsible operator. Obtain the authoritative product PDF and record the exact model, document revision, applicable pages, and operating conditions. Resolve any differences between that document and the catalog extraction.
Request configuration-specific evidence for candidate functions, signal interfaces, operating-state records, data access, switching, and recovery. Assign responsibility for timing review, scheduling, collection, analysis, and acceptance.
Before comparison collection, agree the baseline records, any separate retiming stage, measurement definitions, allocation or matching rules, and treatment of interventions. Before interpreting outcomes, reconcile actual operating states and inspect collection consistency.
The proposed report should distinguish verified equipment features from measured operational outcomes and state the conditions and limitations of each finding.
Additional navigation: Contact. The supplied sources do not establish this route’s availability or supported request types.
Limitations
The supplied pack contains no Lima survey, baseline timing files, measured demand, operating permissions, selected model, or product PDF. It therefore does not establish site feasibility, installation scope, interoperability, certification, or local approval.
The FHWA sources provide United States evaluation context. They do not establish Peruvian requirements or authorize operation in Lima. The FHWA FAQ describes maintained detection as essential to adaptive operation, but provides no product-specific detection evidence for SOLARTODO.
This proposal establishes no collision reduction, emissions reduction, operational improvement, or performance under unobserved conditions. Such claims require supporting evidence appropriate to the selected configuration and evaluated conditions.
FAQ
Is Lima an established deployment?
No. Lima is a proposed evaluation site; the supplied pack contains no local deployment evidence.
Which baseline should the buyer preserve?
Preserve existing timing plans and operating records, check them against actual operation, and document the background plan used for comparison. Record any retiming separately.
How should retiming and candidate-strategy effects be reported?
Report the preliminary retiming comparison separately from the candidate-versus-background comparison. Examine comparability and alternative explanations before attributing observed differences.
When should comparison periods be randomized?
Consider randomization after verifying candidate functions, authorized switching, operating-state records, and recovery arrangements. Agree allocation and transition rules before collection.
Must the pilot copy the Mesa schedule?
No. Mesa is a historical methodological example. The supplied evidence establishes no Lima pilot duration, period length, or sample size.
What if controlled switching is unavailable?
Consider a prespecified matched-period comparison with documented background timings. State the matching criteria, observed differences, and limits on attribution.
Which measures and improvement target are supported?
Select measures linked to the operational objective and obtainable observations. The supplied pack supports no product-specific numerical improvement target.
Can the buyer select an exact model now?
No exact model is established by the supplied evidence. Obtain the authoritative product PDF, exact model, applicable pages, and operating conditions, then verify the proposed functions and interfaces.
References
- SOLARTODO smart-traffic catalog: supplied extraction, catalog identity city-catalog-2026-11-01-v1; equipment-family scope.
- FHWA, Measures of Effectiveness and Validation Guidance for Adaptive Signal Control Technologies, Chapter 1: comparison timing quality, verification and validation, measurement context, and the historical Mesa evaluation.
- FHWA, Adaptive Signal Control FAQs: general adaptive-control operation and detection context.
No product PDF reference is available in the supplied pack; no PDF URL, exact model, PDF page reference, or model-specific operating conditions are established.
Proposed Equipment
- Traffic pole — catalog-family component; selected configuration unresolved
- Camera — catalog-family component; selected configuration unresolved
- Radar — catalog-family component; selected configuration unresolved
- Signal equipment — catalog-family component; selected configuration unresolved
- Edge processing — catalog-family component; selected configuration unresolved