1 / 11

Proposal for Solar Keymark database approach and IT services

This proposal aims to create a solar Keymark database and provide IT services to enhance accessibility and functionality. It includes features like data input structure for certification bodies, interface design, API access, and agreements with third parties.

taylorjames
Download Presentation

Proposal for Solar Keymark database approach and IT services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Proposalfor Solar Keymark database approach and IT services Gerard van Amerongen vAConsult

  2. Revision Solar Keymark database • Binding together 4 SCF projects: • 5C6.1 DATABASE_SKI • Include ‘datasheet’ data and make accessible • 7C04 Label-DB • New Solar Keymark service: • make available ErP relevant data • Add systems (partly) composed of SK certified components (e.g. ErP) • 8C06.1 Add-Value_vAC • Make data accessible for product databases, design tools (third party access) • SCF9 Database-fup • Extend 5C6.1 DATABASE_SKI to systems, tanks and controls • Keep in mind the findings of SKN ‘management table’

  3. Implementation • Implement primary database structure • Copy datasheet data into new structure • Develop and implement the public database user interface • Develop and implement the data input structure certification bodies • Contact ‘third parties’ for access • Design ‘API’ for access • Draft agreements for access (for approval by SKN) • Implement • Implement secondary database element on ErP data • Approval of SKN and promotion • Copy actions for systems and tanks (controls?)

  4. Solar Keymark database • Common approach of all projects • Aim at added value for the Solar Keymark clients • Define the database as the centre and surround with IT services • SKN managed and third party • Target groups • Business to business: • checking licenses • sharing product specifications (e.g. procurement) • Access for third party databases (e.g. product database) • Governmental organisations: • Check specifications for support schemes, ErP surveillance • Installers composing ErP packages

  5. Solar Keymark database - IT infra-structure- • Certiciationbodies: • addby upload datasheet • reviseby upload revised datasheet • License holders: • add/revise ErP system • Download ErP documentation Solar Keymark database • General public: • Select SK product seespecifications • License holders: • Link to relevant parts of database • Third party access: • Product data site • Design tools • Package label tools • Get ErP data + product fiche

  6. Database mainstructure- Public user interface - Direct access throughclients website link Collector List: licenseholders List: collector names Details: one collector Systems List: licenseholders List: system names Details: one system System ErP List: brands List: solardevices Tank Details: ErP data Control

  7. ErP entrance From Solar Keymark database Overlap SolCal SK controller SK collector SK system SK tank ErP documentation Full set of ErP data Compositionfrom different sources Controller Pump Tank From system supplier: • Full set of ErP data • Qnonsol (4x) & Qaux • ηcol + Tank label • ErP documentation • Technical document • Product fiche

  8. Remarks on ErP business • Full set of ErP data can be made available only for: solar water heaters (SOLICS) • For SOLCAL and space (combi) heaters additional data is required • Proposed solution: • Enter new ‘class’ of systems, populated with (license holders) additional data (e.g. pumps, number of collectors, …) • Add (if needed) SOLCAL calculation • Not needed for DST tested systems and space heating purposes • Make ErP data for packages available to the public and third party • E.g. enter Qnonsol / Qaux in VDI product database or LabelPackA+ • Skip SolCal calculations! • Solar Keymark: only documentation (ErP specifications) • For package composing: use LabelPackA+ or another likewise tool (VDI)

  9. Management requirements database • Responsible for data integrity of database • Following the SKN internal regulations • Responsible for data input from certification bodies • Expertise required on Solar Keymark and standards • Goal: within 1 year of implementation new database structure: CB enter the data directly • Database manager supervises the process • Manage third party access • Propose agreements with third parties for access to database (for SKN) • Distribute API’s for that purpose • Helpdesk for CB input, public access and third party access • Keep database and user interfaces up to date • Formulate proposals for improvements (to the SKN)

  10. Points todecideupon • Create a working group (volunteers?) • Purpose of the public user interface • Check licences and read specifications, or • List products with performance data (facilitate: ‘pick the best’) • This means that Solar Keymark supports ‘ranking’ of certifified products • ‘All are good, but some are better’ • Data input options: • The database manager receives the datasheet and enters that in the database (current) • Certification bodies upload the full datasheet • Test laboratories enter the test data & certification bodies enter certification data • An SCF project aimed at the design of this user interface is required

  11. For your attention

More Related