Witam,

Zlecę wykonanie rozwiązania informatyczno elektronicznego do zamontowania w
samochodzie w celu pobierania parametrów pracy silnika (ilość obrotów,
szybkość, ilość paliwa, uruchomienie silnika, etc) i przesyłania ich na
serwer w firmie.

Najważniejsze aby rozwiązanie umożliwiało
- łączenie przez OBD-2 i CAN z komputerem samochodu
- pobieranie podstawowych parametrów pracy silnika
- wysyłanie pobranych danych na serwer z (GPRS lub Windows Mobile)

Opcjonalnie
- zdalnie ustawiać parametry pracy np: czasy pobierania i wysyłania
parametrów (np: co 10 sekund lub co 1 godzinę)
- zapisywać dane w pamięci w przypadku gdy nie ma aktywnego połączenia z
serwerem
- wizualizować pobrane dane w formie np: odzwierciedlenia liczników lub
wykresów badania poszczególnych funkcji np:
aby właściciel firmy mógł kontrolować sposób jazdy kierowców przez
sprawdzanie jak często silnik wchodzi na wysokie obroty co może powodować
jego zacieranie , itp

Klient nie chcę tworzyć rozwiązania informatycznego od podstaw, zależy mu
aby ktoś miał już podobne rozwiązanie które można dostosować do jego
oczekiwań i aby można było później w nie ingerować np: jeżeli właściciel
zażyczy sobie aby pobierać inne dane specyficzne dla tego typu samochodu a
autor nie będzie miał czasu na dalszą kontynuację projektu.

Pozdrawiam i zapraszam zainteresowanych:
Dariusz Kopciowski - SCG

poczta: kopciowski [at] interia.pl
tel.: +48 606-961-328

do góry

Órzytkownik "DariuszK" napisał:
> Zlecę wykonanie rozwiązania informatyczno elektronicznego do zamontowania
> w samochodzie w celu pobierania parametrów pracy silnika (ilość obrotów,
> szybkość, ilość paliwa, uruchomienie silnika, etc) i przesyłania ich na
> serwer w firmie. Najważniejsze aby rozwiązanie umożliwiało
> - łączenie przez OBD-2 i CAN z komputerem samochodu
> - pobieranie podstawowych parametrów pracy silnika
> - wysyłanie pobranych danych na serwer z (GPRS lub Windows Mobile)

a ile puacisz?:O)

do góry

1) CAN to warstwa fizyczna OBD-2
2) OBD-2 nie daje informacji o prędkości samochodu i ilości paliwa

do góry

On Fri, 5 Feb 2010 08:39:15 +0100, William Bonawentura wrote:
>1) CAN to warstwa fizyczna OBD-2

Jesli sie nie myle, to w ODB-2 sa cos 4 warstwy fizyczne, CAN jest
tylko jedna z nich.

sam CAN to dopiero w nowszych pojazdach.


>2) OBD-2 nie daje informacji o prędkości samochodu i ilości paliwa

http://en.wikipedia.org/wiki/Table_of_OBD-II_Codes

Jest i predkosc, i troche o paliwie.

J.

do góry

> Klient nie chcę tworzyć rozwiązania informatycznego od podstaw, zależy mu
> aby ktoś miał już podobne rozwiązanie które można dostosować do jego
> oczekiwań i aby można było później w nie ingerować np: jeżeli właściciel
> zażyczy sobie aby pobierać inne dane specyficzne dla tego typu samochodu a
> autor nie będzie miał czasu na dalszą kontynuację projektu.

...czyli oczekuje, że autor przekaże mu źródła oprogramowania ? Kolega
sobie wyobraża, że takie systemy tworzą ludzie
"dla zabawy" i potem jak "im się znudzi" to porzucają projekt ? heh...

Być może ktoś (jakaś firma) tego typu rozwiązanie ma, ale nie liczyłbym na
podobne warunki jak opisane wyżej.
A zrobić od podstaw - oczywiście można, tylko nie wiem, czy kolega ma
pojęcie o kosztach ?
U mnie w firmie, tak na oko, bez żadnej analizy - coś w okolicach 100.000.
zł., lekko licząc, czas realizacji to kilka miesięcy.
I to na zasadzie sprzedaży klientowi licencji - tj. klient otrzymuje
urządzenia + oprogramowanie, ale oczywiście żadnych źródeł i bez prawa
rozpowszechniania.

Jakby co, to zapraszamy oczywiście :)

pozdr.

do góry

Użytkownik Sundayman <s...@p...onet.pl> w wiadomości do grup
dyskusyjnych napisał:hkh4m1$qi2$...@n...onet.pl...

> ...czyli oczekuje, że autor przekaże mu źródła oprogramowania ? Kolega
> sobie wyobraża, że takie systemy tworzą ludzie
> "dla zabawy" i potem jak "im się znudzi" to porzucają projekt ? heh...

Szanowni Koledzy!
Niniejszym proponuję zakończyć temat piętnowania ludzi którzy oferują tutaj
pracę.
Zapewne pamiętacie Państwo wątek:
"Pilnie poszukiwany Inżynier Elektronik"
Jaka tam się rozpętała dyskusja z domysłami, kłótniami itp.
Ja wtedy nie przyłączyłem się do tej polemiki.
Wydawało mi się to bezcelowe.
Zamiast domysłów, przeszedłem całą drogę rekrutacji, nieskomplikowanej
zresztą.
Rozmawiałem z Panem prezesem.
Mimo iż nie nawiązaliśmy bliższej współpracy, muszę powiedzieć, że
oferta pracy za 10 000 zł/miesiąc była tam realna.
Nie ma więc sensu biadolić.
Po zaznajomieniu się z problemami w tamtej firmie, nadal właściciel może
potrzebować
pracowników do tamtego zadania.
Kto jest bystry, to znajdzie pracę.

A propos kodu.
Mam tu taki fragment do OBD2.
Nie sądzę, aby to był problem przekazać go zamawiającemu,
zwłaszcza, jeśli za niego zapłaci.
Nie uważam tego za skarb.
Nie tak dawno ktoś się mi zapytał, czy nie znam kupca na gotowe projekty,
wyjęte z szuflady po 5000 Euro. Mam takich ze 100.
Jaka jest ich wartość? Chyba naszego szacunku tylko...

--
pozdrawiam
Sylwester Łazar
http://www.alpro.pl
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB

;***************************************************
*****************
;*PROJEKT : TESTER *
;*NAZWA : RECBLOCK *
;*WERSJA : 5.11.1 *
;*mikrokontroler: 18F248 *
;*CZAS : - *
;*ALGORYTM : Recblock.sdr *
;*OPIS : Procedura odbiera blok danych od sterownika. *
;*DATA : 2005/11/14 *
;*WEJSCIE : TR_6, TR_7 - czasy *
;*WYJSCIE : COUNTBK - numer aktualnie odbieranego bloku (będzie *
;* użyty dla bloku nadawanego w procedurze ACKNOW) *
;*STALE : - *
;*PROCEDURY: INCRXDMS, INCTXDMS, INCTXDMPC *
;*MAKRA : jfeql, mov16ff *
;*ZMIENIA : - *
;*UWAGI : *
;***************************************************
*****************
;RECBLOCK.
RECBLOCK
CALL DELAY05MS ;odczekaj czas 10ms
BTFSc bRECEIVED ;Czy otrzymaliśmy dane z STG?
GOTO RECCBYTE ;TAK
DECFSZ WAIT_C,F ;Czy minął określony czas?
GOTO RECBLOCK ;NIE
GOTO RECBERR ;TAK
RECCBYTE
MOVFF PTBUFRDM,FSR1L ;załaduj FSR1 wskaźnikiem bufora ODBIORU (od STG)
MOVFF INDF1,COUNTBT ;zapisz odebrany bajt
CALL INCMSGB ;zwiększ wskaźnik zapisywanej wiadomości
CALL INCRXDMS ;zwiększ wskaźnik odbioru danych (od STG)
MOVF TR_6,w ;załaduj do odmierzania czas tr_6
CALL DELAY_5MS ;odczekaj czas TR_6*5ms
MOVFF PTBUFTDM,FSR1L ;załaduj FSR1 wskaźnikiem bufora NADAWANIA (do STG)
COMF COUNTBT,w ;wyślij negację ostatnio odebranego bajtu
MOVWF INDF1 ;
MOVFF TR_7,WAIT_C ;załaduj do odmierzania czas tr_7
CALL INCTXDMS ;zwiększ wskaźnik bufora nadawania
RECTREC
CALL DELAY05MS ;odczekaj czas 10ms
BTFSc bRECEIVED ;Czy otrzymaliśmy bajt z STG?
GOTO RECCBL ;TAK
DECFSZ WAIT_C,F ;Czy minął określony czas?
GOTO RECTREC ;NIE
GOTO RECBERR ;TAK
RECCBL
MOVFF PTBUFRDM,FSR1L ;załaduj FSR1 wskaźnikiem bufora ODBIORU (od STG)
MOVFF INDF1,TEMPRC ;zapisz odebrany bajt
; CALL INCMSGB ;zwiększ wskaźnik zapisywanej wiadomości
CALL INCRXDMS ;zwiększ wskaźnik odbioru danych (od STG)
MOVFF TEMPRC,COUNTBK ;zapisz odebrany bajt jako licznik bloków
DECF COUNTBT,F ;decrementuj licznik bajtów
RECNXTS
MOVF TR_6,w ;załaduj do odmierzania czas tr_6
CALL DELAY_5MS ;odczekaj czas TR_6*5ms
MOVFF PTBUFTDM,FSR1L ;załaduj FSR1 wskaźnikiem bufora NADAWANIA (do STG)
COMF TEMPRC,w ;wyślij negację ostatnio odebranego bajtu
MOVWF INDF1 ;
MOVFF TR_7,WAIT_C ;załaduj do odmierzania czas tr_7
MOVFF TEMPRC,PTEMPRC ;zapamiętaj ostatnio pobrany bajt
CALL INCTXDMS ;zwiększ wskaźnik bufora nadawania
RECNXTR
CALL DELAY05MS ;odczekaj czas 10ms
BTFSc bRECEIVED ;Czy otrzymaliśmy bajt z STG?
GOTO RECNXBYTE ;TAK
DECFSZ WAIT_C,F ;Czy minął określony czas?
GOTO RECNXTR ;NIE
GOTO RECBERR ;TAK
RECNXBYTE
MOVFF PTBUFRDM,FSR1L ;załaduj FSR1 wskaźnikiem bufora ODBIORU (od STG)
MOVFF INDF1,TEMPRC ;zapisz odebrany bajt
MOVFF TR_6,WAIT_C ;załaduj do odmierzania czas tr_6
CALL INCMSGB ;zwiększ wskaźnik zapisywanej wiadomości
CALL INCRXDMS ;zwiększ wskaźnik odbioru danych (od STG)
DECFSZ COUNTBT,F ;Czy odebraliśmy cały blok?
GOTO RECNXTS ;NIE
jfeql RECBEND,TEMPRC,03h,w ;Czy otrzymaliśmy bajt zakończenia bloku?
RECBERR
BSF bERR ;ustaw informację o błędzie
RECBEND
RETURN

do góry

William Bonawentura wrote:
> 1) CAN to warstwa fizyczna OBD-2

O ile mi wiadomo z bezczelnego podsluchiwania komunikatów latających po
CANie w jednym z samochodów - nie tylko. CAN ma własne, znacznie
ciekawsze życie jak na przykład przesyłanie komunikatow pozwalających na
zdjęcie zabezpieczeń (autoryzacje kluczy) po pierdoły typu kąt
wciśnięcia pedału gazu. Rozgryzienie jednak tego bez dokumentacji
producenta jest trudne, a takowych oficjalnie nie widzę.

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:hkhana$fb9$1@news.onet.pl...

> O ile mi wiadomo z bezczelnego podsluchiwania komunikatów latających po
> CANie w jednym z samochodów - nie tylko. CAN ma własne, znacznie
> ciekawsze życie jak na przykład przesyłanie komunikatow pozwalających na
> zdjęcie zabezpieczeń (autoryzacje kluczy) po pierdoły typu kąt
> wciśnięcia pedału gazu. Rozgryzienie jednak tego bez dokumentacji
> producenta jest trudne, a takowych oficjalnie nie widzę.

I dlatego wykonanie zlecenia będzie obarczone sporym ryzykiem działania
"nie zawsze". Może się skończyć tak, jak w przypadku alarmów samochodowych
(tych podsłuchujących CAN-a) - nie zawsze działają (rozbrojenie potrafi
się "wyminąć" z otwarciem zamka), nie z każdym samochodem i co jakiś czas
są "upgrade'y" :)

e.

do góry

> A propos kodu.
> Mam tu taki fragment do OBD2.
> Nie sądzę, aby to był problem przekazać go zamawiającemu,
> zwłaszcza, jeśli za niego zapłaci.
> Nie uważam tego za skarb.

Zamieszone przez Ciebie tak na oko 30 linijek to skarb może rzeczywiście nie
jest. Ale
aplikacja będąca wynikiem iluś tam tygodni czy miesięcy pracy to już imho
skarbem jest, jako że
jej stworzenie wymaga wydania dość konkretnych pieniędzy. Chyba, że gdzieś
programiści pracują za darmo ?
Ja tam takich rzeczy zatem nie rozdaję, ale może jestem aspołeczny :)

Nikt tu nie "piętnuje" oferujących cokolwiek, a zwłaszcza pracę. Tyle, że
czasem trzeba wskazać realia.
Ale jeśli np. znajdzie się chętny, który ma w szufladzie taki projekt, który
zrobił z nudów, i go udostępni koledze
DariuszK, to proszę bardzo przecież. Tyle, że to - moim zdaniem - mało
prawdopodobne jest...

do góry

On 05/02/2010 12:58, Sundayman wrote:

> I to na zasadzie sprzedaży klientowi licencji - tj. klient otrzymuje
> urządzenia + oprogramowanie, ale oczywiście żadnych źródeł i bez prawa
> rozpowszechniania.

Iii... ja za leniwy na cos takiego jestem. Znaczy jak klient mocno chce,
to produkcje zrobimy. I jak mocno nie chce, to kodu nie damy ;-)
Prosciej mi zawsze jest oddac wszystko (kod/schemat/plytka/vhdl itp) dla
klienta. Jedynie jesli podczas projektu powstanie jakies IP to z reugly
zostawiamy sobie (klient licencje dostaje). W koncu zaplacil za design -
to niech ma i sie cieszy ;-)


--
Jerry1111

do góry