INVESTIGACION Y DESARROLLO DE ENERGIAS RENOVABLES MARINAS SL

INVESTIGACION Y DESARROLLO DE ENERGIAS RENOVABLES MARINAS SL era una societat mercantil constituïda l'any 2009 a Cantàbria, amb un objecte social orientat a la recerca i el desenvolupament en l'àmbit de les energies renovables marines, segons es desprèn de la seva denominació social. El corpus la classifica dins del sector de software i SaaS, tot i que la denominació fa referència explícita a l'R+D en energies renovables marines.

D'acord amb el registre mercantil, la societat consta actualment com a inactiva. El capital social inicial no consta al corpus; l'última xifra registrada és de 5.220.000 euros, resultat d'una ampliació de capital de 4.970.000 euros formalitzada el 2015.

La societat es va constituir el 2009. Les primeres inscripcions registrals documentades al corpus corresponen al 28 de gener de 2009 (nomenament de secretari i cessament d'un conseller) i al 16 d'abril de 2009 (nomenaments al si de la comissió executiva i del consell d'administració), segons consta al BORME.

La composició dels òrgans d'administració va canviar diverses vegades en els primers anys. El 23 d'octubre de 2009 es van nomenar president i secretari, amb cessaments simultanis de càrrecs anteriors. El 24 de febrer de 2010 es va nomenar administrador únic i apoderat, amb cessaments de consellers i del president. El 19 d'octubre de 2010 es va reconstituir el consell d'administració amb el nomenament de president i diversos consellers.

La informació disponible al corpus no permet detallar les activitats concretes, els productes o els clients de la societat. La denominació social indica R+D en energies renovables marines, i la classificació sectorial del corpus la situa en software i SaaS, però no consten al corpus ni la descripció de l'activitat comercial ni els destinataris dels seus serveis.

El corpus no conté dades de facturació, resultats ni nombre de treballadors que permetin descriure l'evolució econòmica de la societat. L'únic element que indica una certa dimensió és l'ampliació de capital de 4.970.000 euros inscrita el 7 de maig de 2015, que va situar el capital subscrit en 5.220.000 euros, segons consta al BORME (T 965, F 135, S 8, H S 20841, I/A 18).

El registre també mostra que la societat va sotmetre els seus comptes a auditoria de forma recurrent: el 2010 es va nomenar DIEZ IZQUIERDO Y ASOCIADOS AUDITORES SL; el 2012, ENRIQUE CAMPOS & AUDITORES SLP; i el 2013, PRICEWATERHOUSECOOPERS AUDITORES SL. Aquest fet indica que la societat estava obligada a auditar comptes, cosa que el registre associa habitualment a societats que superen determinats llindars de dimensió, però el corpus no en concreta les xifres.

El corpus no documenta les causes del cessament de l'activitat ni la data en què es va produir. L'únic fet registral disponible és que la societat consta com a inactiva a la fitxa mercantil consultada (OpenMercantil, a partir del BORME). No consten al corpus ni procediments concursals, ni acords de dissolució, ni cap altra circumstància que expliqui la inactivitat.

El corpus no conté informació sobre actius, patents, projectes, tecnologia o personal que hagin sobreviscut a la societat. No consta cap traça documentada de l'herència de l'empresa.

El corpus identifica com a administradors o consellers GARCIA MONCO CAVADAS FAUSTINO, DIEGO ABASCAL ALFREDO i ROYANO GUTIERREZ FRANCISCO, i recull també els noms d'altres persones que van ocupar càrrecs en diferents moments (SANCHEZ GONZALEZ ROBERTO, GAMARRA CAÑAMERO GERMAN, PEREZ SIERRA MANUEL, RUBIN AGENJO JUAN IGNACIO, CAVADAS RUIZ GABRIEL, CAVADAS RUIZ MARIA CARMEN, CAVADAS RUIZ JOSE LUIS, SANCHEZ ESCALADA JOSE ANTONIO, SUSPERREGUI LETE VICTORIANO, LOPEZ DE ATALAYA SAINZ DE ROZAS DAMASO CARLOS ALFONSO).

Ara com ara no consta al corpus quina és la situació actual d'aquestes persones ni si mantenen vinculació amb altres societats. Per completar-ho es podria consultar el Registre Mercantil de Cantàbria, les fitxes d'aquestes persones a bases de dades mercantils públiques i les fonts periodístiques locals.

• En projectes d'R+D en energies marines, la distància entre la constitució de la societat (2009) i una ampliació de capital significativa (2015) és un indicador del cicle llarg de maduració del sector: cal preveure fonts de finançament sostingudes durant anys abans que la tecnologia generi ingressos.
• L'obligació d'auditar comptes des dels primers exercicis (2010) indica que la societat va assolir aviat els llindars legals de dimensió; en sectors intensius en capital, l'auditoria recurrent és un cost estructural que cal incorporar al pla financer des del començament.
• La rotació d'auditors (tres firmes diferents entre 2010 i 2013) i els canvis freqüents en els òrgans d'administració són senyals que convé monitorar en la governança de societats tecnològiques emergents.
• La classificació sectorial (software i SaaS) no coincideix amb la denominació (energies renovables marines): en l'anàlisi d'empreses tecnològiques cal contrastar sempre la denominació social amb l'activitat real declarada, perquè les bases de dades poden assignar codis sectorials imprecisos.
• Quan una societat consta com a inactiva sense procediment concursal documentat, la verificació de l'estat real exigeix consultar el Registre Mercantil directament, ja que les fitxes agregades poden no recollir tots els actes.

La societat original es va registrar com a "Investigación y Desarrollo de Energías Renovables Marinas" i consta al sector de software i SaaS, amb seu a Cantabria. Les dades verificades no detallen quin producte concret venia, però la combinació de raó social (I+D en energies marines) i sector (software/SaaS) apunta a una tesi raonable: plataforma de programari i dades per al desenvolupament i l'operació de projectes d'energia marina.

La proposta d'avui (marcada com a proposta, no com a fet) seria reconstruir aquesta essència com un SaaS de dades i operacions per a energia marina renovable: modelatge de recursos (onatge, vent, corrents), gestió de dades d'assaigs i dispositius, monitoratge d'actius en mar i eines de suport a la decisió per a promotors i fabricants.

La diferència respecte al 2009 és el context: llavors l'energia marina era gairebé tota en fase de prototip; avui l'eòlica flotant té projectes comercials en marxa a Europa i la digitalització del sector és una necessitat operativa, no un experiment.

El mercat rellevant no és "energia marina" en abstracte, sinó el programari i les dades que necessiten els qui desenvolupen i operen parcs marins. Els compradors potencials són:

• Promotors d'eòlica flotant i fixa que necessiten modelatge de recurs, planificació d'operacions i gestió de dades d'actius.
• Fabricants de dispositius (aerogeneradors flotants, convertidors d'ones) que necessiten telemetria, assaigs i manteniment predictiu.
• Enginyeries, centres de recerca i ports que necessiten eines de simulació i gestió de dades d'assaigs.

És un mercat petit en nombre de clients però gran en valor per compte: pocs projectes, però cada projecte mou pressupostos molt alts i tolera eines especialitzades cares. Això afavoreix un model de nínxol amb preus alts, no un producte massiu.

Nota: no disposo de dades verificades sobre la facturació o els clients de l'empresa original; qualsevol xifra de mercat que es faci servir en un pla real caldrà validar-la amb estudis sectorials (p. ex. WindEurope, IRENA) abans de decidir.

Proposta de model (a validar):

• Subscripció SaaS per projecte o per actiu: llicència anual per a cada parc o dispositiu monitorat. És el nucli recurrent.
• Serveis d'implantació i integració: connexió de sensors, migració de dades, configuració de models. Facturació per projecte, amb marge més baix però que finança l'entrada.
• Mòduls premium: manteniment predictiu, informes regulatoris, bessons digitals de dispositius.
• Possibles acords de dades: licitació de conjunts de dades anonimitzades a centres de recerca i assegurances (a explorar, amb cura legal).

El punt crític és la retenció: un cop la plataforma és dins l'operació d'un parc, el cost de canvi és alt. Per això el model ha de prioritzar pocs clients ben integrats per sobre de molts clients superficials.

Proposta de full de ruta, en fases:

1. Fase 0 — Validació (mesos 0-3): entrevistes amb 10-15 promotors, fabricants i enginyeries del nord d'Espanya i Europa; confirmar quin dolor concret es paga. Cost estimat: 5.000-15.000 € (estimació, a validar).
2. Fase 1 — Producte mínim (mesos 3-9): un sol mòdul (p. ex. modelatge de recurs o monitoratge d'un dispositiu pilot) amb un client pilot. Cost estimat: 60.000-120.000 € (estimació).
3. Fase 2 — Primer contracte de pagament (mesos 9-15): convertir el pilot en subscripció; 1-3 clients.
4. Fase 3 — Escalat comercial (mesos 15-30): equip comercial, segon mòdul, expansió a mercats europeus.

La seu a Cantabria té sentit: hi ha activitat portuària, centres tecnològics i proximitat a aigües amb potencial d'assaigs.

Totes les xifres són estimacions a validar, no dades de l'empresa original:

• Equip fundador mínim (2-3 persones: enginyeria de dades/software + domini marí): 0-90.000 €/any segons si els fundadors es paguen sou des del primer dia.
• Desenvolupament del producte mínim: 60.000-120.000 € en 6-9 mesos (intern o extern).
• Infraestructura cloud i dades: 500-2.000 €/mes en fase inicial (rang estimat).
• Legal, constitució i propietat intel·lectual: 5.000-15.000 €.
• Comercial i viatges: 15.000-30.000 €/any.
• Total per arribar al primer client de pagament: rang estimat de 150.000-300.000 € en 12-15 mesos.

Com a referència, la societat original va arribar a un capital subscrit de 5,22 M€ el 2015 (fet verificat al BORME), però això no indica quant costaria avui un projecte més lleuger i enfocat: la proposta actual és deliberadament més petita i àgil.

• Risc de mercat concentrat: pocs clients potencials; perdre'n un deu fer mal. Cal diversificar geogràficament aviat.
• Risc tecnològic: les dades marines són sorolloses i cares d'obtenir; si el producte no aporta estalvi o precisió demostrable, no es ven.
• Risc de cicle llarg: els projectes marins triguen anys; el cicle de venda pot ser de 6-18 mesos i exigir capital de treball.
• Risc de competència: grans enginyeries i proveïdors de programari industrial poden absorbir la funcionalitat.
• Risc de finançament: el sector deep-tech atrau capital, però amb exigències de tracció; caldrà demostrar pilots reals abans d'aixecar ronda.
• Lliçó del registre: l'empresa original va canviar diverses vegades d'administració i va acabar inactiva; un govern corporatiu estable i un focus de producte clar són condicions per no repetir-ho.

Les lliçons de l'informe original, més que un currículum:

1. La tesi tècnica era bona; el repte era el moment i el focus. El 2009 el mercat marí no estava madur; avui hi ha més compradors reals, però cal un producte concret i no un paraigua ampli.
2. El capital no substitueix la tracció. Una societat amb més de 5 M€ de capital va acabar inactiva: els diners no garanteixen producte ni clients.
3. La governança importa. Els canvis repetits de consellers i administradors al registre suggereixen inestabilitat; un equip fundador estable i alineat és un actiu.
4. Cal un equip híbrid (software + domini marí + comercial) des del primer dia, no només enginyers.
5. Començar petit i vendre aviat: un pilot de pagament val més que un pla de cinc anys.

En resum: la reconstrucció viable avui és una empresa petita, enfocada i amb tracció comercial primerenca, que hereta l'essència de l'original (dades i programari per a energia marina) però no la seva escala ni la seva estructura.

Els operadors de parcs d'energia marina (eòlica flotant, undimotriu, cables submarins) treballen amb dades disperses: SCADA del fabricant, sensors propis, parts de manteniment en fulls de càlcul i obligacions de reporting cap a l'autoritat portuària i el regulador energètic. Això provoca tres problemes concrets:

1. Manteniment reactiu car: les avaries en components submergits (cables, ancoratges, moorings) es detecten tard perquè ningú no creua la telemetria de vibració/temperatura amb l'historial de manteniment. Cada intervenció requereix vaixell i finestra meteorològica, amb costos de 5 xifres per sortida.
2. Reporting manual i fràgil: els informes de disponibilitat i producció es fan a mà, amb errors i sense traçabilitat de la font de cada número.
3. Pèrdua de coneixement: quan marxa un enginyer, marxa el criteri de quan un senyal és "normal" per a aquell actiu i aquella ubicació.

El producte resol això com a capa de govern de dades operatives: un lloc únic on la telemetria es normalitza, s'emmagatzema amb historial auditable, es creua amb el manteniment i genera alertes i informes reproduïbles.

Nota de context: la font registral [BORME / BOE, 2020-08-20] mostra l'empresa com a inactiva i amb una ampliació de capital el 2015 fins a 5.220.000 EUR. El producte parteix de l'experiència tècnica del sector, no de cap actiu de programari existent que es pugui heretar.

Arquitectura de microserveis amb un pla de control (gestió de tenants, actius, usuaris) i un pla de dades (ingesta i consulta), separats perquè la ingesta no es vegi afectada per pics de consulta d'informes.

``` [SCADA / OPC-UA / MQTT]──┐ [Sensors LoRaWAN]─────────┼──> Gateway d'ingesta (MQTT bridge) [CSV/API manteniment]─────┘ │ ▼ Ingest Service (validació + normalització) │ ┌───────────────┼────────────────┐ ▼ ▼ ▼ TimescaleDB Object storage Kafka topic (sèries) (fitxers crus) (esdeveniments) │ │ ▼ ▼ Query API (REST) Rules Engine (alertes) │ │ └──────────► API Gateway ◄───────┘ │ ▼ Frontend (dashboard + informes) ```

Decisions i motius:

• TimescaleDB en lloc d'InfluxDB: necessitem SQL relacional per creuar sèries temporals amb taules d'actius, contractes i manteniment en una sola consulta; Timescale és PostgreSQL amb extensions de compressió i continuous aggregates, cosa que redueix el cost d'operació (un sol motor per a dades relacionals i temporals).
• Kafka per a esdeveniments d'alerta: el motor de regles ha de ser replayable; si una regla canvia, volem recalcular alertes històriques. Kafka reté els esdeveniments i permet reprocessar.
• Gateway MQTT a la vora (edge): els parcs marins tenen connectivitat intermitent (satèl·lit); el gateway fa buffering local i garanteix lliurament at-least-once amb deduplicació per `event_id`.
• Multi-tenant per esquema (un esquema PostgreSQL per operador) en lloc de columna `tenant_id`: aïllament més fort per a dades crítiques d'infraestructura i compliment més fàcil; el cost és més migracions, que es gestionen amb una eina de migració per esquema.

Entitats principals (PostgreSQL + TimescaleDB):

```sql -- Pla de control tenant(id, nom, pla_subscripcio, creat_el) usuari(id, tenant_id, email, rol, mfa_actiu) actiu(id, tenant_id, tipus, fabricant, model, ubicacio_geo, data_instalacio) -- tipus: turbina_eolica | boia_undimotriu | cable_submarí | subestacio component(id, actiu_id, tipus, numero_serie, vida_util_hores) manteniment(id, component_id, tipus, inici, fi, cost, notes, ordre_treball_ref)

-- Pla de dades (hypertable) telemetria( temps timestamptz NOT NULL, actiu_id uuid NOT NULL, sensor_id text NOT NULL, valor double precision, qualitat smallint, -- 0 bo, 1 sospitós, 2 dolent event_id uuid -- per deduplicació ); SELECT create_hypertable('telemetria','temps'); -- retenció: 90 dies en calent, agregats horaris indefinits

alerta(id, tenant_id, actiu_id, regla_id, severitat, estat, oberta_el, tancada_el) regla(id, tenant_id, nom, expressio, finestra, severitat) ```

Decisions i motius:

• `event_id` únic per mostra: la connectivitat marina genera duplicats; la deduplicació a la base evita inflar agregats de producció.
• Camp `qualitat`: els sensors marins donen lectures fora de rang per corrosió o biofouling; marcar-ho permet excloure mostres dolentes dels càlculs de disponibilitat sense esborrar-les (auditoria).
• Agregats horaris continus: els informes regulatoris es fan sobre hores, no sobre segons; precalcular redueix el cost de consulta i fa els informes reproduïbles.

API REST versionada (`/v1`), autenticació OAuth2 client credentials per a integracions i JWT per a usuaris.

• `POST /v1/telemetry:batch` — ingesta en lot (fins a 10.000 punts), idempotent per `event_id`.
• `GET /v1/assets/{id}/timeseries?sensor=&from=&to=&agg=` — consulta amb agregació.
• `GET /v1/alerts?estat=oberta` i `POST /v1/alerts/{id}/ack`.
• `POST /v1/reports/disponibilitat` — genera informe asíncron; retorna `job_id`.
• `GET /v1/reports/{job_id}` — estat i URL signada del PDF/CSV.

Integracions:

• SCADA: connector OPC-UA i Modbus TCP al gateway; mapatge de tags configurable per actiu.
• ERP/manteniment: importació CSV i webhook bidireccional (l'ordre de treball tancada actualitza `manteniment` i tanca alertes associades).
• Webhooks sortints per a alertes crítiques cap a Slack/Teams/PagerDuty.

Motiu: una API de lots idempotent és més robusta que un stream per punt per a clients amb connectivitat dolenta; els informes asíncrons eviten timeouts en consultes llargues.

Ordre de construcció, per valor i per dependències:

1. Model de dades + ingesta per lots idempotent (Timescale + `POST /telemetry:batch`). Sense això no hi ha producte; és la base de tot.
2. Consulta de sèries temporals + dashboard mínim (gràfic per actiu i sensor). Permet validar amb un client pilot que les dades arriben bé.
3. Motor de regles i alertes (llindars simples i mitjanes mòbils). És el primer valor operatiu real.
4. Connector OPC-UA/MQTT per a un fabricant de turbina concret. No generalitzar fins a tenir dos clients.
5. Informe de disponibilitat (agregat horari + PDF). És el que justifica la subscripció davant del regulador.

No construir encara: manteniment predictiu amb ML (cal historial que no tenim), app mòbil, marketplace de connectors.

Mides estimades (any 1):

• 3-5 operadors, ~40 actius, ~2.000 sensors.
• Freqüència 1 mostra/10 s per sensor → ~17 M punts/dia → ~6.000 M punts/any. Amb compressió Timescale (~10x) són ~150-300 GB/any de sèries; assumible en una sola instància amb rèplica.
• Equip mínim: 2 backend, 1 frontend, 1 DevOps/SRE, 1 enginyer de domini.

Riscos tècnics:

• Qualitat de dades de sensor (biofouling, calibratge): mitigació amb el camp `qualitat` i regles de detecció d'outliers; risc que el client no accepti excloure mostres → cal acord contractual sobre què compta com a "disponible".
• Connectivitat intermitent: mitigació amb gateway edge i idempotència; risc de bretxes de dades que fan invàlids els informes → cal marcar explícitament els períodes sense dades.
• Multi-tenant per esquema: migracions costoses a mesura que creix el nombre de tenants; mitigació amb migracions automatitzades i feature flags per esquema.
• Compliment i sobirania de dades: dades d'infraestructura crítica; cal desplegament a la UE i xifrat en repòs i trànsit.

• Pilot amb un operador real durant 8 setmanes: mètriques d'èxit = % de mostres rebudes vs. esperades (>98%), temps mitjà de detecció d'anomalia (<15 min), i que l'informe de disponibilitat generat coincideixi amb el càlcul manual del client (±0,5%).
• Tests d'idempotència: reenviar el mateix lot 3 cops i verificar que el recompte de punts no canvia.
• Tests de càrrega: ingesta sostinguda de 5.000 punts/s durant 1 h amb latència de consulta p95 < 2 s.
• Validació de regles: replay d'un mes de dades històriques amb una regla nova i comparació amb les alertes que hauria generat un expert de domini.
• Auditoria de traçabilitat: cada número d'un informe ha de poder-se traçar fins a les mostres i la versió de la regla que el va produir.